DeepSeek Harness 状态栏只剩 tok/s：performanceUsage 写成 compact 怎么修

刚装好 DeepSeek Harness（DSH），跟着引导选完主题和模型，输入框下方只剩一个 63 tok/s 和缓存命中率，轮数、步数、总 token 全没了。 去设置里看，展示选项明明写着「详细」。这不是渲染 bug：onboarding 在结束时把 performanceUsage 写成 compact，覆盖了默认值，回读校验只比较「值是否相等」，写错了也不报错（来源）。

三处对照：确认 DeepSeek Harness 状态栏被改写

设置页显示 detailed、状态栏只有 tok/s、存储里是 compact，三处同时成立就是 onboarding 覆盖；对不上时以落盘值为准。

1. 打开设置 → 外观/对话，查看「性能展示」当前值。预期：显示 detailed。
2. 看状态栏实际显示了哪些指标。预期：只有 tok/s 与缓存命中率，等于 compact。
3. 打开 profile 的配置文件，搜索 performanceUsage。预期：落盘值是 compact。
4. 对比设置页与落盘值。预期：两者不一致，说明页面读的是默认值。
5. 统计状态栏缺少的项。预期：缺的是轮/步与总 token，正好是 compact 不展示的部分。

据讨论里的源码核对，ui-settings-account/src/client/onboarding-state.ts:113-123 的 finish() 对非 development 一律写 compact，而 ui-chat/src/chat-settings.ts:53 的默认值是 detailed；:171 的回读校验只比较相等（#10339）。

根因：DeepSeek Harness 的 onboarding 为什么覆盖用户选择

finish() 不区分「用户已设置」和「首次默认」，对非 development 环境直接写 compact，把已有的 detailed 冲掉。

1. 用户首次启动，onboarding 收集主题、模型等信息。预期：拿到一份不完整的配置。
2. finish() 组装默认配置。预期：每个字段都被赋了值。
3. 它把 performanceUsage 固定为 compact，没有读 DEFAULT_PERFORMANCE_USAGE。预期：已存在的 detailed 丢失。
4. 写入后回读，只检查写入值与内存值是否相等。预期：语义错误也能通过校验。
5. 设置页展示的 detailed 只是兜底默认值。预期：界面和实际行为分叉。
6. 下次启动继续读落盘值。预期：compact 一直被沿用。

由此产生一个反直觉现象：界面越「正确」，越容易让人以为问题出在渲染层。真正该看的是 profile 目录里的那个字符串。

修法一：在 DeepSeek Harness 设置页重存 detailed

这是最快的临时恢复，适合你只想马上看到轮/步与总 token，不介意下次 onboarding 再被覆盖。

1. 打开设置 → 外观/对话 → 性能展示。预期：控件可编辑。
2. 先切到 compact 保存，再切回 detailed 保存。预期：存储值被真正重写，而不是沿用默认值。
3. 回到会话发一条消息。预期：轮/步与总 token 重新出现。
4. 重启 DSH，再看一次状态栏。预期：启动流程没有把值重置。
5. 如果重启后又变回 compact，说明还有别的写入点。预期：转到修法二或修法三。
6. 记录改动时间。预期：下次复发时能对上日志里的写入点。

设置页重存只改当前这份配置。如果状态栏在重启后又缩回 compact，说明启动流程里还有写入点，别在这里反复试。

修法二：直接改 DeepSeek Harness profile 里的 performanceUsage

设置页不生效或找不到入口时，改 profile 存储最直接；改前备份，只动这一个键。

1. 退出 DSH，确认进程结束。预期：没有进程占着配置文件。
2. 备份 ~/.dsh/profiles/<profile>/。预期：出问题能整体还原。
3. 在该目录搜索 performanceUsage，把 compact 改成 detailed。预期：只改了一处值。
4. 启动 DSH，读取状态栏。预期：四项读数都在。
5. 再走一次 onboarding。预期：如果又被覆盖，说明必须改代码。
6. 检查其他 profile。预期：各自独立，不会被这次修改连带修好。

改存储只解决当前 profile。desktop 和 web 各有一份配置，多端使用时别拿一台的结论套另一台。

修法三：改 DeepSeek Harness 的 onboarding，保住用户已选值

根治方向是让 finish() 尊重已有值，或在非 development 环境不写 performanceUsage；适合维护 fork 或提交上游。

1. 在 onboarding-state.ts:113-123 的 finish() 里，先读当前配置的 performanceUsage。预期：已有值可见。
2. 已有值就跳过写入；没有值则写 DEFAULT_PERFORMANCE_USAGE，不要硬编码 compact。预期：老用户不丢设置，新 profile 拿到 detailed。
3. 把 :171 的回读校验从「相等」改成「值在允许集合内」，写错时给出 warn。预期：错误写入会被暴露。
4. 补三条测试：已有 detailed、已有 compact、无值。预期：三种情况各自符合预期。
5. 重新构建并走一遍 onboarding。预期：状态栏保持你选的展示。
6. 在 PR 描述里附上复现版本。预期：维护者能直接对照 0.2.1-rc.2 的行为。

这条修法要同时照顾两种场景：老 profile 有用户选择，不能被覆盖；新 profile 没有任何值，应该拿到 detailed。测试缺一种，都会在升级后暴露。

验证与边界：DeepSeek Harness 重启与多 profile 复查

四项读数必须同时扛过一次重启和一次 onboarding，修复才算完成；多端用户还要逐个 profile 检查。

1. 看状态栏。预期：轮/步、总 token、tok/s、缓存命中率都在。
2. 重启 DSH。预期：仍然显示 detailed。
3. 走一次 onboarding。预期：值不再被改写。
4. 新建会话与旧会话各看一次。预期：展示一致。
5. 再开一个 profile 对照。预期：没改过的 profile 仍是 compact，符合预期。
6. 核对 token 统计。预期：数值本身不变，只是展示项回来了。

边界有三条：performanceUsage 只影响展示，不影响计费；设置页可能只是在展示默认值；改存储前必须备份。如果你用 DSH插件 同步多台机器的配置，改完要确认插件没有把旧值写回来。讨论里没有官方修复版本，0.2.1-rc.2 仍可复现。统计口径的另一个坑见 tok/s 虚高与 decodeMs 锚点。