DSH / PLUGIN / CLIENT-UI

dsh-client-ui-settings

v0.1.0-rc.5deepseek-ai / deepseek-harness47f943859b

Included in DSHPluginsUI & client pluginsBuilt-in sourceWeb UI
Runtime anatomy
HOSTCLIENTUITOOLDATAFLOW

Overview

dsh-client-ui-settings

Source-level overviewThe settings domain's base layer, with two roles and no presentation of its own. It provides ctx.settingsScope, the Host transport every preference row binds its durable namespace section through, and it declares the settings slot types registrants fill: settings.trigger / settings.header / settings.close (chrome content), settings.action (ordered content-header actions), settings.section (one page per feature), settings.plugins.tab (feature-owned pages inside the Plugins section), and settings.onboarding (ordered feature-owned pages). It depends on no ui-* presentation package, so any feature that owns a preference can reach it; the settings SHELL — the sidebar.settings occupant, its navigation, and the chrome — lives in ui-settings-general, because a shell dependency on ui-sidebar would close a reference graph cycle through ui-layout and ui-theme. The shell's own contract types live beside the shell for the same reason.Read the full technical overviewCollapse technical overview
The settings domain's base layer, with two roles and no presentation of its own. It provides ctx.settingsScope, the Host transport every preference row binds its durable namespace section through, and it declares the settings slot types registrants fill: settings.trigger / settings.header / settings.close (chrome content), settings.action (ordered content-header actions), settings.section (one page per feature), settings.plugins.tab (feature-owned pages inside the Plugins section), and settings.onboarding (ordered feature-owned pages). It depends on no ui-* presentation package, so any feature that owns a preference can reach it; the settings SHELL — the sidebar.settings occupant, its navigation, and the chrome — lives in ui-settings-general, because a shell dependency on ui-sidebar would close a reference graph cycle through ui-layout and ui-theme. The shell's own contract types live beside the shell for the same reason.
BUILT-IN / ATOMIC
Already shipped with DSH — no separate install

This is an atomic module already shipped with Harness, not a standalone profile layer.

Capabilities

What it contributes

HostCordis loadableZero-config
Client / UIWeb UI0 contributions
Model tools0None declared
Profile stateenabledweb

README / EN

Package documentation

@deepseek-ai/dsh-client-ui-settings

English | 中文

The settings domain's base layer, with two roles and no presentation of its own. It provides ctx.settingsScope, the Host transport every preference row binds its durable namespace section through, and it declares the settings slot types registrants fill: settings.trigger / settings.header / settings.close (chrome content), settings.action (ordered content-header actions), settings.section (one page per feature), settings.plugins.tab (feature-owned pages inside the Plugins section), and settings.onboarding (ordered feature-owned pages). It depends on no ui-* presentation package, so any feature that owns a preference can reach it; the settings SHELL — the sidebar.settings occupant, its navigation, and the chrome — lives in ui-settings-general, because a shell dependency on ui-sidebar would close a reference graph cycle through ui-layout and ui-theme. The shell's own contract types live beside the shell for the same reason.

The plugin injects nothing and waits for nothing: ctx.settingsScope.bind(spec) resolves the wire face through the CALLER's context at call time, so the bound scope's disposer belongs to the calling fiber, and the caller injects connection for the transport and remote for the invalidation. Listeners exist before the first background read starts, so a row's activation never blocks on the settings transport. A bound scope reloads on the forwarded settings/document-updated event for its own namespace and on connection/reset. Writes carry one field path and the last known namespace revision as expectedRevision; a rejected or failed write re-reads unless a newer write already superseded it, and a stale read never publishes over a newer one. Without a decode in the spec, a section that is not a plain object, fails its rehydrated schema, or carries a schema envelope this client cannot rehydrate publishes no value at all, so a row renders its own absent state instead of a half-decoded one.

Model Experience

None, as the settings domain base serves browser preference storage and slot declarations; nothing here reaches a model request.

KV Cache effect

None; this package neither assembles nor sends a provider request.

Known Limitations and Deferred Work

  • Remote browsers get no durable settings — the settings RPCs are loopback-only, so a scope bound in a non-loopback browser starts unavailable and never crosses the wire; every row it backs is inert there.
  • One field per writeset sends a single set op, so a row that must move two fields together has no transaction and publishes two revisions.

LIMITATIONS

Known limitations

- **Remote browsers get no durable settings** — the settings RPCs are loopback-only, so a scope bound in a non-loopback browser starts `unavailable` and never crosses the wire; every row it backs is inert there. - **One field per write** — `set` sends a single `set` op, so a row that must move two fields together has no transaction and publishes two revisions.