Client stays pending on DSH 0.1.7-alpha.1 because settingsScope was removed

[GooDAnDReaDY]

What happens

On DeepSeek Harness 0.1.7-alpha.1, @mars-sea/dsh-commandcode-provider 0.11.7 does not activate:

pending (waiting for service: settingsScope)

Web boot then reports that this entry did not activate. The Cordis service settingsScope is no longer provided.

Where

lib/client.js still does ctx.settingsScope.bind({ namespace }) and the client inject list still contains the service id "settingsScope"`.

What to use instead

Read the plugin namespace from configForms (@deepseek-ai/dsh-client-ui-settings):

• ctx.configForms.get(namespace) instead of ctx.settingsScope.bind({ namespace })
• dsh.client.inject should list the provider packages the fiber actually needs, including @deepseek-ai/dsh-client-ui-settings, not the removed service id settingsScope

form.get returns a controller with getSnapshot, subscribe, set, and unset.

[Mars-Sea]

Thanks for the precise report — your "Where" section described 0.11.7's client exactly. This is fixed in 0.11.9, published the same day as your issue, so npm i @mars-sea/dsh-commandcode-provider@latest (or dsh plugin --profile web add @mars-sea/dsh-commandcode-provider@latest) resolves it.

What 0.11.9 changed on 0.1.7-alpha.1:

The client no longer references settingsScope — the bind() call is gone from lib/client.js, and dsh.client.inject lists @deepseek-ai/dsh-client-ui-settings instead of the removed service id, so the fiber activates instead of staying pending.
The settings page keeps working through the plugin's own scope over the remote.settings describe/mutate wire (src/client/settings-scope.ts), with the namespace resolved at runtime via ctx.inject(['remote.settings'], …).
A note on configForms: it's the right pointer for a 0.1.7-only plugin, but this one still supports 0.1.2-rc.1 → 0.1.7-alpha.1, and the describe/mutate wire underneath remote.settings is identical on every one of them (same directory view, same "mutate returns a namespace-view row" contract, same invalidation event) — so one implementation serves both generations instead of branch-by-version. Two related details worth knowing: remote.settings is a Cordis service nested under remote, so a direct ctx.remote.settings read throws cannot get property … without inject (that silent throw is what disabled every control in a separate 0.1.7 report); and the namespace is deliberately not added to the static dsh.client.inject list, since gating the whole client half on a service a profile may not serve would silence every surface instead of degrading it.

The other half of 0.1.7's settings rewrite is covered too: every non-secret Config field is marked volatile through a feature-detected bridge (so the page still reads and writes on 0.1.7 while ≤0.1.6 keeps its old installed path), and the one-time settings.yaml import keys off the entry id llm-commandcode, which matches the section id — existing settings carry over with no user action. Verified with npm run test:engine against a real 0.1.7-alpha.1 tree, and end to end against a real 0.1.7 web app (page converges on the stored row, toggles mark dirty, the model multi-select opens, a save lands in the profile document and survives a reload).

Please reopen if anything still misbehaves on 0.11.9. Thanks again for a clean repro.