Onboarding 将 performanceUsage 改写为 compact，导致 composer 状态栏丢失轮/步与总 token 读数

[xiaozhao1556666]

环境

• DeepSeek Harness Desktop 0.2.1-rc.2（nightly，win-x64）
• 官方 tag：dsh-v0.2.1-rc.2，commit 687f282e8625c6b8d11ff58211a90524be2e4317
• 涉及包：@deepseek-ai/dsh-client-ui-settings-account@0.2.1-rc.2（随 @deepseek-ai/dsh-web-app bundle 安装，非用户显式依赖）

现象

composer 状态栏只剩两个读数：

• 第一个胶囊：仅 63 tok/s，缺少 N 轮 M 步
• 第二个胶囊：仅 缓存命中 93%，缺少总 token 数

预期（performanceUsage: detailed）应显示 N 轮 M 步 · 63 tok/s 与 总 token · 缓存命中 93%。

根因

packages/client/ui-settings-account/src/client/onboarding-state.ts 中，DesktopOnboardingController.finish() 在引导完成/跳过时，无条件把 usage 写入 Chat 的 performanceUsage：

usage: development ? 'detailed' : 'compact', developerTools: development,

只有 purpose: development 分支给 detailed，office 与 skipped 一律 compact。写入通过 settings.mutate() → ConfigEditor.edit() 直接落盘到 $DSH_HOME/profiles/<name>/cordis.patch.yml。

问题在于两侧默认值互相矛盾：

侧	字段	默认值
dsh-client-ui-settings-account	usage（schema default）	compact
dsh-client-ui-settings-account	freshProgress().usage	'compact'
dsh-client-ui-chat	DEFAULT_PERFORMANCE_USAGE	"detailed"

即：用户从未做过任何选择，onboarding 一构造/一完成就把默认 detailed 降级为 compact。

影响面

比「走过 onboarding 的用户」更大 —— 所有新建 profile 都会命中，因为 freshProgress() 的 usage 初始值就是 'compact'。

又因为 tok/s 和缓存命中仍然显示，仅丢失轮/步计数和总 token 数，所以极易被忽略。

另有两个相关的既有讨论，但均为功能建议而非本 bug：
#3431（嫌 dock 统计挤在一行要省略号）、
#1781（建议精简状态栏条目）。
两者都不涉及 performanceUsage 被静默改写。

复现

1. 全新 profile，走引导到 purpose 步骤，选 office 或直接 skip
2. 观察 ~/.dsh/profiles/<name>/cordis.patch.yml
3. 可见 ui-chat 段被写入 performanceUsage: compact

证据

受影响机器上三个历史 patch 备份（cordis.patch.yml.bak-*）中 performanceUsage 均为 detailed，仅当前文件为 compact，证明是 onboarding 写入而非用户修改或版本升级导致。

逐层核对（均已验证一致）：

官方 GitHub tag dsh-v0.2.1-rc.2 (687f282e)
  └─ onboarding-state.ts: usage: development ? 'detailed' : 'compact'
       ├─ npm @deepseek-ai/dsh-client-ui-settings-account@0.2.1-rc.2
       │    └─ lib/client.js (minified, :3300)
       │         └─ app.asar 内副本 sha256 1fa932b2dbf1079a40e164fc082c6d81efa5e2bd741c85360356505dceaa724c
       └─ ~/.dsh/profiles/desktop/cordis.patch.yml  ← 被写成 compact

另一台机器的实时底栏确认渲染路径无缺陷 —— performanceUsage: detailed 时 2 轮 46 步 · 206 tok/s 与 1.8M tok · 缓存命中 96% 均完整显示。结合 ActivityPill / UsagePill 中 if (mode === "compact") return … 的直白分支，可确认唯一变量是配置值本身，而非渲染逻辑、版本回归或第三方插件干扰。

附带发现（同一文件的其它问题）

以下三条同样来自 onboarding-state.ts，均已在 dsh-v0.2.1-rc.2 官方源码中确认：

1. retry() 会重放陈旧的 usage 值 —— failedWrite 保存的是当时完整的 progress 对象，retry() 原样重放，会覆盖用户后续的手工修正。
2. finish() 把 process 隐式耦合到 Chat 的 transcriptView —— process: office ? 'compact' : reason === 'skipped' ? 'standard' : current.process，该值经 chat.mutate([{ op: 'set', path: ['transcriptView'], value: mode }]) 写入，但 schema 上无任何说明表明二者耦合。
3. derive() 的 api-key 自动保存分支硬编码 process 与 developerTools —— void this.save({ ...progress, step: 'done', process: 'standard', usage: 'detailed', developerTools: true, completion: 'api-key' }, true)，会冲掉用户手工设置。

建议修复

任选其一：

1. 将 finish() 与 freshProgress() 的 usage 默认值改为 'detailed'，与 Chat 侧对齐；
2. 或让 onboarding 在用户未显式选择时不写入 performanceUsage，交由 Chat 侧默认值生效；
3. 或在 Chat 设置 UI 中暴露该开关，使用户可自行恢复。

建议同时处理附带发现 1（retry() 不应重放已被用户修正的字段）。

临时规避

在 ~/.dsh/profiles/desktop/cordis.patch.yml 中显式固定：

- id: ui-settings-account
  name: "@deepseek-ai/dsh-client-ui-settings-account"
  config:
    step: done
    usage: detailed
- id: ui-chat
  name: "@deepseek-ai/dsh-client-ui-chat"
  config:
    performanceUsage: detailed

step: done 可关闭 finish() 与 derive() 两条写入路径，usage: detailed 保证即使路径意外打开，写回的也是正确值。

[PerryLink]

两处默认值确实冲突，而且同一个控制器里还有第三条分支写成 detailed，所以现在的值取决于你从哪个分支走完引导，而不是取决于用户选了什么。

默认值这一侧：packages/client/ui-chat/src/chat-settings.ts:53

export const DEFAULT_PERFORMANCE_USAGE: PerformanceUsageMode = 'detailed'

写入这一侧：packages/client/ui-settings-account/src/client/onboarding-state.ts:113-123，finish() 里

usage: development ? 'detailed' : 'compact', developerTools: development,

而同一个文件 :230 的 api-key 收尾又是

void this.save({ ...progress, step: 'done', process: 'standard', usage: 'detailed', developerTools: true, completion: 'api-key' }, true)

再配合 :12 的初始状态 usage: 'compact'，这个字段在三个地方有三个来源。落盘通过 :168 的 { op: 'set', path: ['performanceUsage'], value: next.usage }，:171 还会回读校验，所以它是真的写进了 cordis.patch.yml，不是只在内存里。

我要补的一点判断：这个字段是显示偏好（状态栏显示多细），不是引导流程的产物。用户在引导里没有选择过它，finish() 就不该写它 —— 现在非 development 一律写 compact，等于用一个与问题无关的分支覆盖掉 detailed 的默认值。最小修法是 finish() 在 purpose !== 'development' 时干脆不 set 这个字段，让默认值生效；另一种是让引导真的问一次显示偏好。

报告里值得强调的还有那个回读校验（:171）：它会因为 saved.performanceUsage !== next.usage 抛 Chat preferences were not saved，也就是说写入失败会有报错，但写入成功且值不对是没有任何提示的 —— 这正是这条 bug 难被发现的原因。