0.2.1-alpha.2 删除了公开服务 webRuntime，但迁移指南挂在了 v0.2.1-alpha.1 目录下，release notes 也无提示｜breaking change without an entry of its own

[iuuuuuuuu]

0.2.1-alpha.2 相对 0.2.1-alpha.1 删除了 Web 侧的公开服务 webRuntime（连同 web-runtime 行的 trustedHosts 配置面）。这个破坏性变更有迁移正文、但没有自己的 upgrade-guide 条目，release notes 里也没有任何指向，于是第三方插件在升级后集体静默失效。下面是我在本机（Windows 10 19045 / DSH 0.2.1-alpha.2 + nightly 桌面壳）做逐 tag 比对后的取证结论。

1. 结论：变更本身有文档，只是被挂在了 alpha.1 名下

• 迁移指南正文存在且完整：docs/upgrade-guide/v0.2.1-alpha.1/web-listener-trust-config/{guide.md,guide.zh.md,guide.i18n.yaml}，description 逐字：

  The Web profile replaces the webRuntime service and the web-runtime row's trustedHosts config with webStartup, and rejects a wildcard listener host.

  正文给出 5 步迁移（inject 换 webStartup / 表达式换 ctx.webStartup.trustedHosts 并删 lanAddresses / connection overlay 重写 / wildcard host 换具体地址 / --dump-config 预览）。

版本解析链（自证不存在版本漂移）：annotated tag dsh-v0.2.1-alpha.2 = 6851e496… → tag object → commit d743267388641bc76f17c45ce8b4c231aed1d32c，与 commits/master 的 HEAD 同点；本次核对的所有 tag 级结论都建立在同一个 commit 上。

• 但 docs/upgrade-guide/ 在 tag dsh-v0.2.1-alpha.2 与 master 上都只有 v0.1.7-rc.2 / v0.2.0-rc.2 / v0.2.1-alpha.1 三个目录，没有 v0.2.1-alpha.2；在 tag dsh-v0.2.1-alpha.1 上目录存在（18 个文件、2 个版本位），但还没有 v0.2.1-alpha.1/ 子目录 —— 即这份指南是 tag 之后（10-04 的 commit）才加进去的。（★ 更正：原文曾写作「该目录根本不存在」；2026-10-14 经 PerryLink 指出后按 git/trees/…?recursive=1 复核修正 —— alpha.1 tag = 18 blobs，alpha.2 tag = 78 blobs。）
• alpha.2 的 release notes（GET https://api.github.com/repos/deepseek-ai/deepseek-harness/releases/tags/dsh-v0.2.1-alpha.2 → published_at 2026-10-09T11:09:26Z，body 长度 9594 字符）按词频逐项统计：webRuntime / webStartup / web-runtime / trustedHosts 均 0 次；宽松正则 webRuntime|webStartup|web-runtime|web-startup|upgrade-guide|迁移|trustedHost 只命中 2 行，全部与本变更无关：
  • 「侧栏 Fork 和子代理目录浏览新增迁移提示，遇到需要迁移的会话时引导用户先打开原会话。 @imccyu」
  • 「Agent Team 消息改为直接投递目标 Inbox，移除独立 outbox、自动重试和重发去重；相关配置与结果字段需迁移。 @Dudu-0223」
  • 说明：迁移 出现 3 次但只落在上述 2 行内（L52 一行两次）；「体验优化」里关于 Web 监听只有一行「Web 支持绑定指定的 IPv4/IPv6 地址，并通过 --tls-cert 和 --tls-key 配置原生 HTTPS 监听」，与本变更无关。

也就是说：维护者写了正确的文档，但按「目录名 = 变更首次落地的 release」的命名约定，读者要在 alpha.2 上遇到问题，得先去翻 alpha.1 的目录，而 release notes 不会告诉他要翻。

2. 归因：逐 tag 比对 + 唯一破坏性 commit

事实	dsh-v0.2.0-rc.2	dsh-v0.2.1-alpha.1	dsh-v0.2.1-alpha.2
packages/bundle/web-app/src/index.ts 中 const WEB_RUNTIME_SERVICE = 'webRuntime' + ctx.provide(WEB_RUNTIME_SERVICE, runtime)	有（L38 / L231）	有（L40 / L250）	整块删除，0 命中
同文件 resolveLanTrust(ctx.webServer.host, config.trustedHosts)（绑定地址隐含信任）	L226 / L131	L242 / L142	已移除
docs/upgrade-guide/ 下是否有该变更的指南	—	目录不存在	无 alpha.2 条目，指南在 alpha.1 目录下
tag 发布日	2026-09-29	2026-10-03	2026-10-09

唯一破坏性 commit：cb9a590c8 "Support concrete Web listener bind addresses"（作者时间 2026-10-04T12:30:28Z，80 个文件）。命中点：

• packages/bundle/web-app/src/index.ts +57/−66、packages/bundle/web-app/cordis.patch.yml +14/−14（web-runtime 行新增 inject: [webStartup]）、packages/client/connection/src/api-request-trust.ts +34/−13、packages/client/connection/src/index.ts +3/−5、packages/client/connection/src/rpc-host.ts +7/−2、packages/host/webserver/src/index.ts +101/−5
• 删除 packages/bundle/web-app/tests/trusted-hosts.spec.ts
• 同一个 commit 新增 docs/upgrade-guide/v0.2.1-alpha.1/web-listener-trust-config/guide.md +36/−0（+guide.zh.md / +guide.i18n.yaml）

即「删服务」和「写迁移指南」是同一次提交完成的 —— 文档不是漏写，而是目录名标在了 alpha.1 上，而变更实际第一次落地在 alpha.2。另外 webStartup 并不是新名字：它在 rc.1/rc.2/alpha.1/alpha.2 四个 tag 上都是 packages/bundle/web-app/src/startup.ts 里同一行 export const WEB_STARTUP_SERVICE = 'webStartup'。所以对外看起来像「改名」，实际是删掉一个聚合服务并改变信任语义，而 release notes 没有给出这个信号。

3. 这个缺口在用户侧的放大形态（第三方插件集体静默不挂载）

插件 inject 里的 webRuntime 永远等不到提供者 ⇒ 条目停在 pending (waiting for service: webRuntime) ⇒ 宿主只打一条 dsh: warning: 1 entry did not activate，HTTP 侧表现为空体 405/404（serve-static 兜底），插件自己的 UI 仍在（客户端 half 独立加载），用户看到的是「侧边栏能开、文件树/git 全 405」。

跨平台独立报告（都是同一个根因）：omdsh-dev/DSH-better-sidebar #906（macOS / Win11 / Linux 至少 4 台机器）、#931（要求给挂载门禁 pnpm test:mount 的 DSH pin 加 alpha 通道 lane）、修复 PR #905 / #932；另有 @huanlin/dsh-plugin-better-sidebar-plugin-office 0.2.0 受影响。

4. 请求

1. 把该指南补到 docs/upgrade-guide/v0.2.1-alpha.2/（或在 v0.2.1-alpha.1/web-listener-trust-config 条目里注明「该变更自 alpha.2 起生效」），并在 alpha.2 release notes 的「其他变更」加一行 breaking 提示。仅此一条就能把上面整类故障的排查时间从「翻源码」压到「读一行」。
2. （弱请求，同题已有 [Feature] An entry that fails to activate is only a launcher warning while health stays 200 — make it fatal or visible to readiness #9067）条目卡在「等待一个永远不会出现的服务」时目前只是 launcher warning，health 仍 200。本贴只补充一条可复现观测供该讨论参考：这类条目的 HTTP 表现是空体 405，不是插件自己的 JSON 错误体 —— 排查时可以据此一刀切开「宿主没挂载」与「插件路由写错」。

English summary

On 0.2.1-alpha.2, the public webRuntime service (and the web-runtime row's trustedHosts config surface) was removed by commit cb9a590c8 "Support concrete Web listener bind addresses" (2026-10-04, 80 files). The migration guide written by that same commit lives at docs/upgrade-guide/v0.2.1-alpha.1/web-listener-trust-config/ — but docs/upgrade-guide/ has only v0.1.7-rc.2, v0.2.0-rc.2 and v0.2.1-alpha.1 on both master and tag dsh-v0.2.1-alpha.2, so the release that actually broke third-party plugins has no entry of its own, and the alpha.2 release notes contain no line about it. webStartup was never a new name (it is the same WEB_STARTUP_SERVICE export in rc.1/rc.2/alpha.1/alpha.2); the change deleted a service and altered trust semantics rather than renaming one. Effect on third parties: any plugin that injects webRuntime stalls at pending (waiting for service: webRuntime) with only dsh: warning: 1 entry did not activate, and its HTTP routes answer an empty-body 405 while its client half still renders. Independent reports: omdsh-dev/DSH-better-sidebar #906 (macOS/Win11/Linux), #931, PRs #905/#932. Request: publish the guide under docs/upgrade-guide/v0.2.1-alpha.2/ (or cross-reference it from the alpha.1 entry) and add one breaking-change line to the alpha.2 release notes.

[PerryLink]

你这条诉求成立，而且我确认了变更与文档出自同一个提交 —— 所以这不是"漏写文档"，而是目录归属问题。但你有一处硬错要先改掉，否则维护者会拿它否掉整条报告。

1. ✅ 核心事实：变更与文档同属一个提交

• git log -1 cb9a590c8 → Support concrete Web listener bind addresses，Yichen Yan，Sun Oct 4 20:30:28 2026 +0800，80 个文件
• 该提交 新增 了 docs/upgrade-guide/v0.2.1-alpha.1/web-listener-trust-config/guide.{md,zh.md,i18n.yaml}（--name-status 可见）

⇒ 指南不是忘了写，而是被放进了 v0.2.1-alpha.1/ 目录。

• 指南正文（origin/master）的 description 与你引的逐字一致：

The Web profile replaces the webRuntime service and the web-runtime row's trustedHosts config with webStartup, and rejects a wildcard listener host.

• git ls-tree -r dsh-v0.2.1-alpha.2 -- docs/upgrade-guide → 只有 v0.2.0-rc.2 / v0.2.1-alpha.1 两级 ⇒ alpha.2 名下确实没有自己的目录，你观察到的错位是真实的。

2. ⚠️ 但你有一处硬错：「在 tag dsh-v0.2.1-alpha.1 上该目录根本不存在」

实测：git ls-tree -r dsh-v0.2.1-alpha.1 -- docs/upgrade-guide → 14 个文件（含 v0.1.7-rc.2/*、v0.2.0-rc.2/*）。

⇒ 正确说法是：

该 tag 上 docs/upgrade-guide/ 目录存在，但没有 v0.2.1-alpha.1/ 子目录 —— 因为这份指南是 tag 之后（10-04）的提交才加进去的。

这个区别很重要：按你原来的写法，维护者一句"目录明明存在"就能把报告带偏；按修正后的写法，就精确指向"新目录被建在了一个已经发过版的版本位下"这个实际问题。

（另：你提到"release notes 正文 9594 字符" —— 那个数字像是帖子字数被误写进来了，与本变更无关。release notes 不在 git 里，我无法核实，建议这一条要么删掉，要么改成"请人工核对"。）

3. 你判断对的部分

webStartup 不是新名字 —— packages/bundle/web-app/src/startup.ts:23 → export const WEB_STARTUP_SERVICE = 'webStartup'，在 rc.1 / rc.2 / alpha.1 / alpha.2 四个 tag 上都是同一行。（被删的是 WEB_RUNTIME_SERVICE = 'webRuntime'：dsh-v0.2.1-alpha.1:packages/bundle/web-app/src/index.ts:40 与 :250 的 ctx.provide(WEB_RUNTIME_SERVICE, runtime) 与你标注逐行吻合，而 alpha.2 上对 WEB_RUNTIME_SERVICE|webRuntime|resolveLanTrust 在 src/ 与 cordis.patch.yml 里零命中。）

⇒ 所以你"不是改名、是删除一个服务"的判断成立。

4. ⭐ 指南正文已经写清了你关心的症状（建议直接引它）

guide.md 里那句：

A profile, overlay, or --patch file that injects webRuntime now waits for a service that never mounts

这正是"静默 pending"的权威表述，而且它就写在指南里。⇒ 你可以据此把诉求收得更准：

变更本身有文档、且文档已说明失败形态；问题只是 alpha.2 的用户找不到它（指南挂在 v0.2.1-alpha.1/ 下）。

5. 建议的修法（按代价排序）

1. 最轻：在 guide.md 正文加一行「该变更自 dsh-v0.2.1-alpha.2 起生效」—— 一行，不动目录结构；
2. 在 alpha.2 的 release notes 里指向该指南；
3. 新建 docs/upgrade-guide/v0.2.1-alpha.2/ —— ⚠️ 但这会与其它条目的版本位约定不一致（看 git ls-tree，目录是按变更首次落地的 release 命名的，而这次变更恰好跨了 tag 边界）。建议把方案 3 作为备选并说明其代价，而不是当作首选。

6. 边界

• 我核的是 origin/master = d743267388（= dsh-v0.2.1-alpha.2）以及三个 tag 上的 docs/upgrade-guide 与 bundle/web-app。
• ⚠️ 无法核实：alpha.2 的 release notes 内容（不在 git 里）、以及你提到的外部仓引用。第 2 节那处更正请你自己再对一遍 git ls-tree，那是本条报告里唯一会被反驳的点。

[iuuuuuuuu]

感谢核对，尤其是第 2 节那处 —— 你是对的，我那句话写错了，我先更正，再把你标为「无法核实」的两点补上可复核的取数方式。

0. 更正：tag dsh-v0.2.1-alpha.1 上目录存在，缺的是子目录

我复核了一遍：

gh api 'repos/deepseek-ai/deepseek-harness/git/trees/dsh-v0.2.1-alpha.1:docs/upgrade-guide?recursive=1'
→ blobs = 18，truncated = false
   v0.1.7-rc.2/schedule-optional-bundle/guide.{i18n.yaml,md,zh.md}
   v0.1.7-rc.2/transcript-view-legacy-normal/guide.{…}
   v0.2.0-rc.2/account-sign-in-errors/guide.{…}
   v0.2.0-rc.2/remove-runtime-invariants/guide.{…}
   v0.2.0-rc.2/schedule-bundle-retired/guide.{…}
   v0.2.0-rc.2/subpath-plugin-display-manifest/guide.{…}

⇒ 正确表述是：该 tag 上 docs/upgrade-guide/ 存在（18 个文件、2 个版本位），只是没有 v0.2.1-alpha.1/ 这个子目录。我原文写成「该目录根本不存在」，属于把「子目录尚未创建」误述成「目录不存在」—— 这确实是一句维护者可以直接反驳的话，谢谢指出。按你建议的改法，问题才精确落在「新版本位被建在一个已经发过版的 tag 之下」上。

（同一个 ?recursive=1 查询在 tag dsh-v0.2.1-alpha.2 上是 blobs = 78、3 个版本位，即 v0.2.1-alpha.1/ 下 18 个条目是在 alpha.1 发版之后才出现的 —— 这一点与 git ls-tree -r 的结论一致。）

1. release notes 不是「无法核实」，它就在 GitHub Releases 上

我漏了给出取数命令，补上（我本地重跑过，数值与上次一致）：

gh api repos/deepseek-ai/deepseek-harness/releases/tags/dsh-v0.2.1-alpha.2
→ tag_name = dsh-v0.2.1-alpha.2, published_at = 2026-10-09T11:09:26Z
  body 长度 = 9594 字符
  用 /webRuntime|webStartup|web-runtime|web-startup|upgrade-guide|迁移|trustedHost/i 逐行匹配 → 2 行命中：
    - 侧栏 Fork 和子代理目录浏览新增迁移提示，遇到需要迁移的会话时引导用户先打开原会话。 @imccyu
    - Agent Team 消息改为直接投递目标 Inbox，移除独立 outbox、自动重试和重发去重；相关配置与结果字段需迁移。 @Dudu-0223

两条都与本变更无关 ⇒ 「alpha.2 的 release notes 里没有 webRuntime 删除的提示」这一条可以留，而且现在有可复现的取数方式。

2. 另外确认一处引用：alpha.2 tag 与 master 同点

git/ref/tags/dsh-v0.2.1-alpha.2 → object 6851e496… (type: tag)
  → tag object → commit d743267388641bc76f17c45ce8b4c231aed1d32c
commits/master → d743267388641bc76f17c45ce8b4c231aed1d32c

⇒ 你核的 origin/master = d743267388 = dsh-v0.2.1-alpha.2 成立，我上面所有 tag 级结论也都建立在这同一个 commit 上。

3. 按你的建议收窄后的诉求

变更本身有文档、且文档已写明失败形态（guide.md 里那句 a profile, overlay, or --patch file that injects webRuntime now waits for a service that never mounts）；问题只是 alpha.2 的用户找不到它。所以：

1. 首选：在 v0.2.1-alpha.1/web-listener-trust-config/guide.md（及其 zh/i18n 三份）加一行「该变更自 dsh-v0.2.1-alpha.2 起生效」—— 一行，不动目录结构。
2. 其次：alpha.2 的 release notes 指向该指南。
3. 备选：新建 docs/upgrade-guide/v0.2.1-alpha.2/ —— 采纳你的提醒：这会与「目录名 = 变更首次落地的 release」的既有约定冲突（本次变更恰好跨了 tag 边界），代价要一并写明，不作为首选。

我这边的原始报告已按第 0 节更正（本地留档里那句已改成「目录存在、缺子目录」）。

[PerryLink]

这次轮到我更正两处，而且都是我的错。另外你补的取数方式让我把一个原本标为「无法核实」的点真正核实了 —— 结论对你有利。

1. ⚠️ 更正一：那份清单是 18 个文件，不是我写的 14

我上一条写「git ls-tree -r dsh-v0.2.1-alpha.1 -- docs/upgrade-guide → 14 个文件」。这个数字是错的，实测：

(git ls-tree -r dsh-v0.2.1-alpha.1 -- docs/upgrade-guide | Measure-Object -Line).Lines
→ 18

明细与你的 API 输出完全一致：

• v0.1.7-rc.2/ 下 2 个 guide × 3 份（guide.md / guide.zh.md / guide.i18n.yaml）= 6
• v0.2.0-rc.2/ 下 4 个 guide × 3 份 = 12
• 合计 18

⇒ 你是对的，我把子目录数当成了文件数。 你的 gh api … git/trees/…?recursive=1 给出的 18 blobs 是正确取法。（这条更正只影响我那句旁证，第 2 节的主更正不受影响 —— 那一处你确实写错了，你也已经改了。）

2. ⚠️ 更正二："9594" 不是帖子字数 —— 那是 release notes 的真实长度，你原来的数字是对的

我上一条说：

你提到"release notes 正文 9594 字符"—— 那个数字像是帖子字数被误写进来了，与本变更无关。release notes 不在 git 里，我无法核实。

两句话都错了。 我按你给的思路用 REST 取了 alpha.2 的 release：

GET /repos/deepseek-ai/deepseek-harness/releases/tags/dsh-v0.2.1-alpha.2
→ status 200
  tag: dsh-v0.2.1-alpha.2   name: v0.2.1-alpha.2
  published: 2026-10-09T11:09:26Z
  body 长度: 9594            ← 正是你写的那个数

⇒ 9594 就是 release notes 正文的长度。你原报告里那个数字准确无误，是我把它误判成"帖子字数"并让你删掉 —— 请不要删，那是正确的可复核数字。抱歉。

3. ⭐ 顺带把我原本标为「无法核实」的那一点核实掉了：你的判断成立

同一次 REST 取到的 release body 里，四个关键词的命中数：

关键词	命中
webRuntime	0
webStartup	0
web-runtime	0
trustedHosts	0

⇒ 「alpha.2 的 release notes 完全没有提到这个破坏性变更」—— 这一条现在是已验证的 TRUE，不再是我上一条说的"无法核实"。

建议你把它写进报告，并附上取数方法（这比任何叙述都硬）：

GET https://api.github.com/repos/deepseek-ai/deepseek-harness/releases/tags/dsh-v0.2.1-alpha.2
→ body 中 grep "webRuntime" / "webStartup" / "web-runtime" / "trustedHosts" 均为 0

我上一条之所以说"不在 git 里"，是因为 release body 确实不在仓库对象里 —— 它存在 GitHub Release 一侧，用 Releases API 取，而不是 git。这是我说错的地方，取数路径你找对了。

4. ✅ 你对 tag 与 commit 的对应也核实无误

git/ref/tags/dsh-v0.2.1-alpha.2 → tag object 6851e496… → commit d743267388641bc76f17c45ce8b4c231aed1d32c
commits/master                  → d743267388641bc76f17c45ce8b4c231aed1d32c

⇒ dsh-v0.2.1-alpha.2 与 master 同点，这也正是我核对时用的基准（origin/master = d743267388）。所以我们两边所有 tag 级结论都建立在同一个 commit 上，不存在版本漂移的可能 —— 这一点值得写进报告，它能一次性挡掉"是不是版本不同"的质疑。

5. 关于你的诉求排序（我认可，并补一句）

你把三条按 首选/其次/备选 排好、并把"目录名 = 变更首次落地的 release"这一约定与它的代价写清 —— 这正是这条报告应该有的形态。

补一句让首选更容易被采纳：把那一行写成两个版本位的关系，而不是只写一个日期，例如：

该变更自 dsh-v0.2.1-alpha.2 起生效（本指南位于 v0.2.1-alpha.1/，因为改动首次落地于该 tag 之后、alpha.2 发布之前）。

这样维护者既看到生效版本，也看到"为什么它挂在 alpha.1 目录下"——把最可能被反问的那一点先答掉。

6. 边界

• 我重新核了：git ls-tree -r dsh-v0.2.1-alpha.1 -- docs/upgrade-guide（18 行，已贴出明细）、以及上表那次 Releases API 调用（status 200、body 长度 9594、四个关键词 0 命中）。
• 我没有核实你引用的 @imccyu / @Dudu-0223 那两条 release 条目属于哪个范围（你判断它们与本变更无关，我采信）—— 那需要逐条比对 PR，超出本次核对范围。
• 本文第 1、2 节是对我上一条的更正，请以本文为准。

[iuuuuuuuu]

三条更正互相抵消掉两条 —— 净值只剩「文件数 18」，而这一点你已经自己更正了。逐项对齐：

点	现值	谁的错
docs/upgrade-guide/ @ alpha.1 tag 的文件数	18（v0.1.7-rc.2 2 条 ×3 + v0.2.0-rc.2 4 条 ×3），明细与你贴的一致	你先写 14，现已更正为你我的共识
release notes 正文长度	9594 字符，published_at 2026-10-09T11:09:26Z	原数字正确，保留（我按你的要求不删）
webRuntime / webStartup / web-runtime / trustedHosts 在 release notes 中的命中	各 0 次	一致
tag dsh-v0.2.1-alpha.2 → commit	tag 6851e496… → d743267388641bc76f17c45ce8b4c231aed1d32c = commits/master HEAD，同点	一致

我按你的意见收紧了一处措辞

你提醒「9594 疑似帖子字数」之后我重测了口径，发现自己那句表述松：原写「逐行匹配 webRuntime|webStartup|web-runtime|upgrade-guide|迁移|trustedHost 只命中 3 行」，而实际按行统计是 2 行 —— 迁移 出现 3 次，但集中在 2 行内（L52 一行两次）。我把正文改成了两个口径分开写，避免再出现这种一句话能被追问的缝隙：

GET https://api.github.com/repos/deepseek-ai/deepseek-harness/releases/tags/dsh-v0.2.1-alpha.2
  → published_at 2026-10-09T11:09:26Z ; body 长度 9594
  → 词频统计: webRuntime=0  webStartup=0  web-runtime=0  trustedHosts=0
  → 宽松正则 ...|迁移|... 命中 2 行（均与本变更无关）:
      L44 侧栏 Fork 和子代理目录浏览新增迁移提示… @imccyu
      L52 Agent Team 消息改为直接投递目标 Inbox…相关配置与结果字段需迁移。 @Dudu-0223

你建议的「附上取数方法」我照做了 —— 现在这条不是叙述，是一次可重跑的调用 + 可核对的数字。

已写进正文的两处

1. 版本解析链（你指出的、能一次性挡掉「是不是版本不同」的那条）：annotated tag → tag object → commit → 与 master 同点，已作为引用块放在目录那节的入口。

2. 首选修法按你的措辞改写成「两个版本位的关系」，拟写入 guide.md 的句子：

   This change takes effect from dsh-v0.2.1-alpha.2; this guide lives under v0.2.1-alpha.1/ because the change landed after that tag and before alpha.2 shipped.

   ZH 对应：

   该变更自 dsh-v0.2.1-alpha.2 起生效；本指南位于 v0.2.1-alpha.1/，是因为该改动落地于该 tag 之后、alpha.2 发布之前。

   （guide.i18n.yaml 需同步同一句。）

需要的话我可以把最小 diff 直接贴上来

三份文件各加 1 行，我可以在这里贴完整 diff 供你们内部挑一份合入。我不擅自开 PR —— 按 CONTRIBUTING.md「We are sorry that we cannot accept external pull requests at the moment.」，外部 PR 不被接受，走 Discussion 更合适。

需要我现在就贴 diff 吗？（另：@imccyu / @Dudu-0223 那两条 release 条目是否真与本变更无关，我核的是行内容而非 PR 归属，这一点维持你的「采信」判断即可。）

[LUgABeEEE]

0.2.1-rc.2 fallout: plugins that read webRuntime.trustedHosts silently become loopback-only

We upgraded a LAN deployment 0.2.0-rc.2 → 0.2.1-rc.2 today (Linux, Node 22.22, dsh web --trusted-host <lan-authority> behind a TCP forwarder). Three community plugins still do the lazy lookup:

const rt = ctx.get?.('webRuntime') ?? ctx.webRuntime
const trusted = rt?.trustedHosts ?? []

After the upgrade, with unchanged plugin code:

• dsh-memory@2.0.0 — /api/dsh-memory/status → 403 this endpoint is local-only from a LAN Host (loopback still 200)
• @linxin666/dsh-ssh@0.4.6 — /api/dsh-ssh/* → 403 forbidden: loopback-only
• @linxin666/dsh-client-ui-git-graph@0.4.6 — /git/* → 403 forbidden: loopback-only

Renaming the lookup to webStartup restores all three (verified 200/200/405). Two problems remain for plugin authors:

1. webStartup is provided by @deepseek-ai/dsh-web-app, not the harness base — headless/SDK/ACP profiles do not mount it, so it cannot serve as a general trust contract.
2. The fallback is silent: no load-time warning, no deprecation alias. Users only see 403s in the UI.

Could you (a) expose a profile-independent trust source (service or env such as DSH_TRUSTED_HOSTS) that any plugin can read, or (b) keep a deprecated webRuntime alias for one minor release with a startup warning, and (c) add the removal as its own breaking-change entry (it currently only appears under v0.2.1-alpha.1)? This is the same trust gap tracked in #9029, now hitting third-party plugins rather than only the settings page.

Local workaround: we patch the three plugins per release and can test a core-provided helper when available.