Alpha.3 Web profile cannot load rc.8-era plugins

[FreeCodeCampXYG]

Compatibility issue: alpha.3 core cannot load rc.8-era @linxin666/dsh-web-ui-all@0.2.5

Environment

• DSH core/runtime: @deepseek-ai/dsh@0.1.2-alpha.3
• Node.js: v24.19.0
• Host package: FreeCodeCampXYG/starline-dsh-desktop
• Reproduction package/release: Starline DSH Desktop v0.6.17
• Windows portable offline runtime, launched with the Web profile

Reproduction

1. Keep an existing Web profile that enables @linxin666/dsh-web-ui-all@0.2.5.
2. Start the profile with the alpha.3 offline runtime.
3. The loader reports repeated plugin import failures and the Web profile does not start successfully.

Representative errors:

The requested module '@deepseek-ai/dsh-settings' does not provide an export named 'installSettingsSection'
The requested module '@deepseek-ai/dsh-settings' does not provide an export named 'settingsNamespace'
Cannot find package '@deepseek-ai/dsh-host-apiproxy'

The failing imports originate from the installed @linxin666/* plugin packages under the user's Web profile. The current alpha.3 runtime provides @deepseek-ai/dsh-settings@0.1.2-alpha.3; the plugin package metadata still declares the older ^0.1.0-rc.8 API line.

Expected behavior

Could alpha.3 either provide a compatibility path/error classification for older Web plugins, or document the required plugin version boundary? A clear startup diagnostic would also help users distinguish an incompatible persisted profile from a broken offline runtime.

Workaround

Disabling/removing the old @linxin666/dsh-web-ui-all bundle from the Web profile allows testing the base profile separately. I have not deleted sessions, credentials, or the packaged runtime.

Thanks for confirming whether an alpha.3-compatible release of the plugin family is planned, or whether the profile should be migrated/reinstalled against a new plugin contract.

[oliblue-evan]

这是核心 alpha 线破坏性变更导致的插件不兼容，不是你打包流程的问题——rc.8 时代的插件在 alpha.3 核心上加载不了是预期结果。

机制：报错缺的两个导出（settingsNamespace / installSettingsSection）是 rc 时代 @deepseek-ai/dsh-settings 的公开 API，alpha 线重构设置系统时被移除/改名了（同样的还有槽位契约从 list 改 keyed、若干类型更名如 CallId → ToolCallId）。rc.8 时代构建的插件（@linxin666/dsh-web-ui-all@0.2.5 等）在 ESM import 阶段就直接失败，loader 重试后放弃，profile 起不来。

你的桌面发行版的处理选项（按可行性排序）：

1. 双轨打包：Starline 里按发行线配对打包——rc.8 线的 runtime 只带 rc 兼容插件，alpha.3 runtime 只带已适配 alpha 的插件。离线便携场景这是最稳的。
2. 等/推插件适配：alpha 线还在快速破坏性迭代期（官方 README 也明确 compatibility-breaking），现在追 alpha 的插件成本很高；建议在 alpha.3 的包里暂时剔除这些 rc 时代插件，让 Web profile 至少能裸起。
3. 给用户锁定：对依赖 rc 插件的用户，发行版里直接固定 rc 线版本，等插件生态跟上再升。

给插件作者的适配提示（如果你要联系 @linxin666）：需要把 settingsNamespace/installSettingsSection 的用法迁移到 alpha 的设置注册方式，同时 settings.plugin.item 槽位注册要补 key 字段——这两处都改完才能在 alpha.3 上加载。

一句话：核心和插件必须同线配对，alpha 线目前每一步都可能破坏插件 API。

[FreeCodeCampXYG]

Windows WebView2 follow-up

The core and profile now start successfully after removing the rc.8-era plugins, but the embedded Windows WebView2 surface still cannot complete alpha.3 browser authentication. The server returns the expected redirect and session cookie; the same token URL works in the system browser, while the embedded surface lands on the upstream authentication-required page.

For now, Starline DSH Desktop v0.6.20 opens the verified URL in the system browser and retains Desktop as the lifecycle/diagnostics shell. No DSH user data is deleted.

Observed Windows screenshot:

Could you confirm whether the alpha.3 browser-auth flow is expected to support Windows WebView2 hosts, or whether an embedding host needs an explicit cookie/session handoff API?

[FreeCodeCampXYG]

感谢说明，已经按你建议做了实测确认。

我在 Windows 的 D:\winsofts\dsh-desktop 上使用 @deepseek-ai/dsh@0.1.2-alpha.3 离线运行时，先移除了 Web Profile 中的 @linxin666/dsh-web-ui-all@0.2.5，随后又移除了仍依赖 rc 时代 dsh-settings API 的 dshmarket@1.14.1。移除后，基础 Web Profile 可以正常启动，说明插件移除后 alpha.3 核心本身是可以使用的；我保留了 sessions、credentials、attachments 和其他用户数据，没有清空整个 .dsh。

目前还剩一个与插件无关的问题：系统浏览器打开 DSH 打印的一次性 URL 可以完成 303 跳转并进入页面，但同一个 URL 在 Windows WebView2 中会落到：

dsh web authentication required; reopen the URL printed by dsh web.

服务端返回的认证链包含 HttpOnly; SameSite=Strict 会话 cookie。我的桌面壳当前是 Go/Wails，已尝试 iframe 和 WebView 顶层导航；两者在 WebView2 中都无法保留该 cookie，而系统浏览器正常。截图和复现版本在这里：

• 项目：FreeCodeCampXYG/starline-dsh-desktop
• 复现 Release：v0.6.20
• 截图：Windows WebView2 认证回退

想请教一下：你们是否遇到过 alpha.3 在 Windows WebView2/嵌入式浏览器中无法完成这个 cookie 交接的问题？这个认证流程是否要求 Chromium 系浏览器的特定请求头、Origin、CookieManager 或显式的 cookie/session handoff API？如果目前官方只保证系统浏览器，桌面宿主可能需要按你说的双轨方案处理。