DeepSeek Harness status bar drops turns after onboarding

A fresh DeepSeek Harness install finishes the setup wizard and the status bar under the composer shows only 63 tok/s and a cache hit rate; turns, steps and total tokens are gone although the settings page says detailed. This is not a rendering bug. Onboarding's finish() writes performanceUsage as compact, overwriting the default, and the read-back check only compares values for equality, so a wrong write passes silently (source).

Compare three places in DeepSeek Harness before editing

Settings showing detailed, the bar showing compact data, and the stored value being compact together identify onboarding as the writer; when they disagree, trust the stored value.

1. Open settings, then appearance or conversation, and read the performance display option. Expected: it reports detailed.
2. Read the status bar and list the metrics that actually appear. Expected: only tok/s and cache hit rate, which is compact.
3. Open the profile configuration and search for performanceUsage. Expected: the file says compact.
4. Compare page and file. Expected: they disagree, which means the page renders a default.
5. List the missing readouts. Expected: turns, steps and total tokens, exactly what compact hides.

The discussion's source review pins the write to ui-settings-account/src/client/onboarding-state.ts:113-123, where finish() writes compact for every non-development environment, while ui-chat/src/chat-settings.ts:53 declares detailed; the read-back at :171 only compares equality (#10339).

Why DeepSeek Harness onboarding overwrites a deliberate choice

finish() does not separate a user choice from a first-run default, so it replaces whatever value exists.

1. The first launch collects theme and model preferences. Expected: a partial configuration in memory.
2. finish() assembles the object it intends to persist. Expected: every field receives a value.
3. It hard-codes performanceUsage as compact without reading DEFAULT_PERFORMANCE_USAGE. Expected: an existing detailed value is lost.
4. The read-back compares the write with memory. Expected: a semantically wrong value still passes.
5. The settings page renders the declared default. Expected: the UI and the behaviour split.
6. The next launch reads the stored compact value. Expected: the wrong setting persists.

The counter-intuitive part is that the interface looks correct while the persistent state is wrong. Always check the profile store rather than the control.

Repair 1: resave detailed in the DeepSeek Harness settings

This is the fastest visible recovery, and it is enough if a future wizard run overwriting the value does not bother you.

1. Open settings, appearance or conversation, then performance display. Expected: the control is editable.
2. Switch to compact and save, then switch back to detailed and save. Expected: the stored value is rewritten instead of inherited.
3. Send one message in a session. Expected: turns, steps and total tokens reappear.
4. Restart DeepSeek Harness and read the bar again. Expected: startup does not reset the value.
5. If compact returns, another writer exists. Expected: you move on to repair 2 or 3.
6. Note the time of the change. Expected: the next relapse can be matched against a log entry.

Resaving only rewrites the current configuration. If the bar collapses back to compact after a restart, another writer runs during startup, so stop repeating this step.

Repair 2: edit performanceUsage in the DeepSeek Harness profile

When the settings control is missing or ineffective, change the single key in the profile store; back up first and touch nothing else.

1. Quit DeepSeek Harness and confirm no process remains. Expected: the files are no longer held.
2. Back up ~/.dsh/profiles/<profile>/. Expected: the whole profile can be restored.
3. Search that directory for performanceUsage and replace compact with detailed. Expected: exactly one intended value changes.
4. Start the app and read the bar. Expected: all four readouts are visible.
5. Complete onboarding again. Expected: if compact returns, the writer needs a code fix.
6. Inspect the other profiles. Expected: they stay independent and are not repaired by this edit.

A profile edit only fixes the profile you touched. Desktop and web keep separate stores, so do not assume one result covers the other.

Repair 3: make DeepSeek Harness onboarding keep the chosen value

The durable fix is for finish() to preserve an existing value and to use the declared default when none exists; this suits a fork or an upstream patch.

1. In onboarding-state.ts:113-123, load the current performanceUsage before writing. Expected: an existing choice is visible.
2. Skip the write when a value exists; otherwise write DEFAULT_PERFORMANCE_USAGE, never a literal compact. Expected: existing users keep their setting and new profiles get detailed.
3. Change the read-back at :171 to check membership in the allowed set and warn on failure. Expected: a bad write is surfaced.
4. Add three tests: detailed present, compact present, and no value. Expected: each case behaves as designed.
5. Rebuild and run the wizard once. Expected: the bar keeps your chosen display.
6. Put the reproducing version in the pull request. Expected: maintainers can compare against 0.2.1-rc.2.

The patch has to serve two cases: an older profile with a user choice that must survive, and a new profile with no value that should receive detailed. Missing one test leaves a regression for upgrades.

Verify and set bounds for DeepSeek Harness

The repair is complete only when all four readouts survive a restart and a wizard run; multi-device users must check each profile.

1. Read the bar. Expected: turns, steps, total tokens, tok/s and cache hit rate all appear.
2. Restart DeepSeek Harness. Expected: it still shows detailed.
3. Complete onboarding once. Expected: the value is no longer rewritten.
4. Compare an old and a new session. Expected: both render the same layout.
5. Open another profile as a control. Expected: an untouched profile stays compact.
6. Check token totals. Expected: the numbers do not change, only the visible fields return.

Three limits apply: the setting is cosmetic and never changes billing, the settings page may only show a default, and the store must be backed up before editing. If you sync profiles with a DSH plugin, confirm the plugin does not write the old value back. No official fix version appears in the discussion, and 0.2.1-rc.2 still reproduces. For the related metric flaw, see tok/s inflation and the decodeMs anchor.