0.1.7-alpha.1: legacy client service settingsScope silently removed — third-party plugins hang on boot and the failure surfaces as a misleading client-half failed

[eddiedon]

Version: DSH 0.1.7-alpha.1 (npm, Windows 11, web profile). Upgraded from 0.1.6-alpha.2.

Symptom

After upgrading, multiple third-party plugins with dsh.client.inject fail:

• @xgone/dsh-remote 0.3.3 — entry permanently pending (waiting for service: settingsScope) (0.1.7-alpha.1: bundle stays pending (waiting for service: settingsScope) — client half injects a service removed by the settings-architecture migration xgone/dsh-remote#20)
• @dingyi222666/dsh-session-notification 0.1.19 — web boot: 1 entry did not activate ...: failed (0.1.7-alpha.1 client 半激活失败：uiSession.pendingInteractions 已被移除（并入 sessionStatus） dingyi222666/dsh-session-notification#5)
• @michengai/dsh-automation 0.1.45 — abnormal after upgrade
• Only dsh-cost-meter 1.7.32 works

What we verified (so the report doesn't chase the wrong direction)

• The client injection/module surface is intact: dsh-client-modules browser half is byte-identical (SHA256) between 0.1.6-alpha.2 and 0.1.7-alpha.1, and the manifests of all five plugins comply with the documented contract (dsh.client.platform: "web" + optional inject). The per-plugin failures have unrelated root causes (see linked issues).
• settingsScope appears zero times in the entire 0.1.7 package tree. 0.1.7 moved settings to per-profile plugin configuration (release notes: "custom settings plugins must adapt") and deleted the legacy client services without an alias or shim. dsh-settings now provides a service named settings whose document is the profile patch; settings.yaml is one-time imported (renamed .imported).
• Because a failed host-half fiber takes the whole plugin down, the Plugin Manager surfaces these as a misleading "client-half failed" shape, which misdirects debugging toward the (verified intact) injection surface.

Requests

1. Keep a deprecated alias for removed legacy settings client services (settingsScope) for one release, or make the boot/Plugin-Manager diagnostic name the removed service (e.g. "service X was removed by the settings migration — see release notes") instead of a bare pending/failed.
2. Attribute activation failures to the failing half (host/client) with the waiting/throwing service name.

Secondary (same migration family)

dsh plugin CLI exits 1 inside runPluginCommand (lib/plugin-DJ-rVHUS.js) already on 0.1.6-alpha.2, which broke dshmarket-driven installs/updates before the upgrade (log timestamps 2026-09-22 11:54–12:14 local, .dsh-market/log.ndjson); full stack available. The same package installs fine via direct pnpm --dir <profile> add (7.8 s once the store is warm).

Linked per-plugin reports

• 0.1.7-alpha.1: bundle stays pending (waiting for service: settingsScope) — client half injects a service removed by the settings-architecture migration xgone/dsh-remote#20
• 0.1.7-alpha.1 client 半激活失败：uiSession.pendingInteractions 已被移除（并入 sessionStatus） dingyi222666/dsh-session-notification#5

[wangzhanchao883]

顺着这个补 host 侧那一半：settings.register 加上 scope.get() / scope.watch() 也是整套删掉的，插件要改成 export const Config，每个可写字段都得盖 .volatile()（少盖一个，条目会被 describe() 静默过滤，面板无声消失）。还有个更隐蔽的：写入不会再触发插件重载，插件如果只在 apply 时读一次配置，面板改了等于没改——我就因此在「面板里加了扫描目录、点扫描却说没设置」上报错。改法是每个入口重读一次 settings.describe()。细节我写在 #7873。

The host half is gone too (settings.register + scope.watch): migrate to export const Config with every writable field marked .volatile(). Note that a write no longer re-applies the plugin, so re-read settings.describe() at every entry point — details in #7873.