b462d5fd69
Adapt to two contract changes master introduced: - The generated Remote face now wraps every business result in RemoteResult, folding carrier failures into an ok:false branch instead of rejecting. The controller reads that envelope at its three call sites and maps a carrier failure onto the same settled shape the controls already render; three specs cover the new branch. - Client packages split their tsconfig into host and client halves, and the host aggregate now compiles any test not named *.client.spec.*. Rename this package's specs to the client convention and drop the ../connection project reference, which pointed at a solution file that no longer carries the client sources. Keep master's mount loop with its rollback-on-failure in api-remotes and add messageFeedbackRemote to it.
@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), 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
unavailableand never crosses the wire; every row it backs is inert there. - One field per write —
setsends a singlesetop, so a row that must move two fields together has no transaction and publishes two revisions.