Third-party plugin contract violation crashes the entire plugin tree, killing the Web UI (dsh 0.1.2-rc.1)

[yxloveql]

Bug Report: Third-party plugin contract violations crash the entire plugin tree and whiteout the Web UI

Project: deepseek-harness (@deepseek-ai/dsh)
Version: 0.1.2-rc.1
Node: 24.x
Platform: Linux (WSL2), systemd-managed
Severity: High — total Web UI outage
Reporter: (community user)

---

1. Summary

A single third-party plugin installed into a dsh profile can bring down the entire
plugin tree, not just itself. Because the failure occurs inside apply(), cordis
aborts the whole loader chain, dsh app-boot throws, the process exits, and systemd
restarts it — producing a crash-restart loop where the HTTP port is bound but never
serves a working page.

The plugin in question was authored against a different plugin contract (OpenClaw's)
and violated three dsh-specific rules. Two of them are host-side and fatal; the third is
client-side and silently whiteouts the page while the server looks healthy.

The core request of this report: dsh currently offers no defense-in-depth here.
A malformed third-party plugin is indistinguishable from a broken installation to the
operator, and the diagnostic surface (Web UI) is destroyed by the very failure it should
report.

---

2. Environment

Item	Value
dsh version	0.1.2-rc.1
Install path	/usr/local/lib/node_modules/@deepseek-ai/dsh/
Profile	~/.dsh/profiles/web
Plugin install path	~/.dsh/profiles/web/node_modules/dsh-ocgo-guard/
Supervisor	systemd unit dsh-web
Listen address	127.0.0.1:3080

Plugin files involved

dsh-ocgo-guard/
├── package.json          # declares dsh.bundle.patch + dsh.client.inject
├── cordis.patch.yml
└── lib/
    ├── index.js          # host half
    └── client.js         # client half

package.json declared:

"dsh": {
  "bundle": { "patch": "./cordis.patch.yml" },
  "client": {
    "inject": [
      "@deepseek-ai/dsh-client-ui-slots",
      "@deepseek-ai/dsh-client-ui-conversation",
      "@deepseek-ai/dsh-client-modules"
    ],
    "platform": "web"
  }
}

cordis.patch.yml mounted the host half:

- insert:
    - id: ocgo-guard
      name: 'dsh-ocgo-guard'

---

3. Symptoms

Superficially the Web UI "would not open". The misleading part is that the service
reported healthy:

$ systemctl is-active dsh-web
active

$ ss -ltnp | grep 3080
LISTEN 0 511 127.0.0.1:3080 ...

The port was bound, the unit was active, and yet the page never rendered. Two distinct
failure modes were present simultaneously:

Failure half	Observable symptom
Host half broken	Process exits during boot → systemd restart loop. curl cannot complete a request.
Client half broken	Server is healthy, HTTP works, but the browser renders a blank page.

This distinction matters and is worth documenting: an operator who only checks
systemctl is-active will conclude the service is fine and look elsewhere (DNS, firewall,
the Windows winnat port reservation issue, browser cache) — while the real fault is a
plugin.

Crash-restart loop evidence

$ systemctl show dsh-web -p NRestarts
NRestarts=34

Across the incident window (12:13–12:34), the journal shows 163 distinct process
PIDs and 50 occurrences of plugin tree failed to load.

---

4. Root cause

4.1 Defect A — reading an undeclared service property (fatal)

lib/index.js:140 accessed a cordis service property without declaring it in inject:

The failing statement was at lib/index.js:140 inside apply(). The property it read
was timeout — the cordis Proxy reported it directly:

Error: cannot get property "timeout" without inject
    at .../dsh-ocgo-guard/lib/index.js:140:22

In schematic form:

// lib/index.js (broken) — apply() reads an undeclared service property
const x = ctx.timeout          // ← line 140 in the original file

The exact source line is no longer readable: the file has since been patched, and the
line now holds a try {. The line numbers below are taken verbatim from the journal.

cordis uses a Proxy that throws on access to a property that was not declared via
inject. The resulting error is not a normal undefined:

Error: cannot get property "timeout" without inject
    at file:///home/<user>/.dsh/profiles/web/node_modules/dsh-ocgo-guard/lib/index.js:140:22
    at new apply (file:///home/<user>/.dsh/profiles/web/node_modules/dsh-ocgo-guard/lib/index.js:142:7)
    at Fiber.execute (.../cordis/lib/index.js:1067:24)

Note for readers comparing against other write-ups of this incident: the property in
the actual log is timeout, not timer. The author's own summary said timer;
the journal is authoritative.

Because this threw inside apply(), the failure propagated up the entire loader chain:

Error: dsh: plugin tree failed to load: failed to apply loader entry include (cordis:include):
failed to apply loader entry ocgo-guard (dsh-ocgo-guard): cannot get property "timeout" without inject

Stack, unwound:

  [cause]: Error: failed to apply loader entry include (cordis:include): ...
      at updateError (.../cordis-plugin-loader/lib/index.js:309:9)
      at Entry._init   (.../cordis-plugin-loader/lib/index.js:529:10)
      at async Entry.init   (.../cordis-plugin-loader/lib/index.js:505:4)
      at async Entry.update (.../cordis-plugin-loader/lib/index.js:426:37)
      at async EntryGroup.create (.../cordis-plugin-loader/lib/index.js:65:4)
      at async EntryGroup.update (.../cordis-plugin-loader/lib/index.js:97:21)
    [cause]: Error: cannot get property "timeout" without inject

dsh-app-boot then rethrows and the process dies:

file:///usr/local/lib/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-app-boot/lib/index.js:1511
                throw new Error(`${binName}: ${stage}: ${detail}${stack}`, { cause });
                      ^
    at boot (.../dsh-app-boot/lib/index.js:1511:9)
    at async runProfile (.../dsh/lib/profile-boot-BTzzdrGY.js:261:14)
    at async file:///usr/local/lib/node_modules/@deepseek-ai/dsh/lib/bin.js:130:3
Node.js 24.x

Key observation: the error is attributed to ocgo-guard, but the blast radius is
plugin tree failed to load — every other plugin in the profile is collateral damage.

4.2 Defect B — relying on a sandbox-only global (fatal, independent)

After Defect A was patched, a second, unrelated error surfaced. lib/index.js:230
referenced a bare harness identifier:

// lib/index.js (broken)
harness.handle('...', ...)
harness.defineTool('...', ...)

harness is a closure symbol provided only to sandboxed dynamic packages (the
code environment). An ordinary cordis plugin loaded from node_modules has no such
global:

Error: dsh: plugin tree failed to load: failed to apply loader entry include (cordis:include):
failed to apply loader entry ocgo-guard (dsh-ocgo-guard): harness is not defined
ReferenceError: harness is not defined
    at Fiber.<anonymous> (file:///home/<user>/.dsh/profiles/web/node_modules/dsh-ocgo-guard/lib/index.js:230:30)
    at new apply (file:///home/<user>/.dsh/profiles/web/node_modules/dsh-ocgo-guard/lib/index.js:230:9)

Because the reference was reached through new apply(...), the ReferenceError fired
during plugin construction — same total-outage outcome as Defect A. This error appears
55 times in the journal.

4.3 Defect C — client half shipped as bare ESM (white screen)

lib/client.js was authored as plain ESM:

export const name = '...'
export function apply(ctx) { ... }

But dsh's browser-side loader requires a CJS factory module:

window.__ModuleLoader__.load({ id, factory })

The ESM export token is a syntax error to that loader, so the entire client bundle at
/plugins/??... fails to parse:

Uncaught SyntaxError: Unexpected token 'export'

Diagnostic asymmetry worth noting: this error appears 0 times in journalctl.
It exists only in the browser console. An operator debugging purely from server-side
logs will never see it — which is exactly why the symptom "server healthy + blank page"
is so hard to attribute.

4.4 Contributing factor — sandbox-only symbols used in a third-party bundle

The client half also referenced styles, host, and fetch as free variables. These are
host-provided closure symbols exclusive to sandboxed dynamic packages. In an external
bundle they are undefined:

Uncaught ReferenceError: styles is not defined

This is a documentation/contract-discoverability gap rather than a separate bug: nothing
in the plugin-authoring surface warns that harness/styles/host/fetch/setTimeout
are unavailable outside the sandbox.

---

5. Reproduction

1. Create a dsh profile with at least one healthy plugin.
2. Install a third-party plugin whose apply() reads an undeclared service property:

   return { name: 'x', apply(ctx) { const t = ctx.timeout } }   // no inject declaration

3. sudo systemctl restart dsh-web
4. Observe the service enters a restart loop; the port is bound but no page renders.

Minimal reproduction of Defect A (host):

// node_modules/bad-plugin/lib/index.js  —  no `inject` on the returned object
module.exports = {
  name: 'bad-plugin',
  apply(ctx) {
    const t = ctx.timeout      // throws: cannot get property "timeout" without inject
  },
}

Minimal reproduction of Defect C (client):

// node_modules/bad-plugin/lib/client.js  —  bare ESM instead of __ModuleLoader__.load
export const name = 'bad-plugin'
export function apply(ctx) {}

---

6. Diagnosis procedure (what actually worked)

The decisive insight: do not trust systemctl is-active. Check the restart counter.

# 1. Is it looping, or is a port genuinely unavailable?
systemctl show dsh-web -p NRestarts
# NRestarts growing between checks ⇒ crash-restart loop, NOT a port problem

# 2. Find the plugin and the exact contract violation
journalctl -u dsh-web -n 60 --no-pager | grep -iE "plugin tree|without inject|is not defined"

# 3. Rule out ports (was never the issue here)
ss -ltnp | grep 3080

# 4. Page-level truth — client-half errors exist ONLY here
#    Open the Web UI URL with ?token=... in a CDP/headless browser and read the console.

Two things that cost time and should be documented:

• patchReload: live (hot reload) does not save you. When the plugin tree itself
  fails to load, the hot-reload path fails too. Only a full
  sudo systemctl restart dsh-web reflects reality. Several hot-reload attempts
  reported success while the page stayed broken.
• A plain curl http://127.0.0.1:3080/ returning 401 is normal, not a fault —
  the URL carries a token. Do not chase this as a bug.

---

7. Workaround / fix applied

Host half (lib/index.js):

• Wrapped every undeclared-service access in try/catch, since the cordis Proxy throws
  rather than returning undefined:

  const timerSvc = (function () {
    try {
      const t = ctx.get('timer')
      if (t && typeof t.timeout === 'function') return t
    } catch (e) {}
    try {
      if (typeof ctx.timeout === 'function') return ctx
    } catch (e) {}
    return undefined
  })()

• Replaced the missing timer service dependency with a built-in setTimeout watchdog,
  so the plugin degrades instead of failing when cordis-plugin-timer is absent.
• Replaced bare harness usage with an existence check
  (typeof harness !== 'undefined') placed before harness.handle /
  harness.defineTool calls — note that harness.handle && harness.handle(...) does
  not work, because the bare identifier is resolved before the && short-circuits.

Client half (lib/client.js):

• Rewrapped as a CJS factory:

  window.__ModuleLoader__.load({
    id: '...',
    factory: (require) => {
      const exports = {}
      exports.name = '...'
      exports.inject = ['slots', ...]
      exports.apply = function (ctx) { ... }
      return exports
    },
  })

• Replaced the styles closure symbol with a self-injected <style> element.
• Soft-acquired the host channel via ctx.get('host') inside try/catch; when
  unavailable, the badge is skipped rather than throwing.

Result: service stable, NRestarts=0, page renders (verified via CDP).

---

8. Requests / suggestions for the project

These are the actionable asks; the bug itself is in a third-party plugin, but the
amplification is in dsh.

1. Isolate plugin load failure. One plugin's apply() throwing should disable
   that plugin only — not abort the whole tree and kill the process. Prefer
   per-entry containment with the failure surfaced in the UI.
2. Fail open for the diagnostic surface. If the plugin tree is broken, the Web UI
   should still boot far enough to display the failure. Currently the failure destroys
   the only place a user could learn about it.
3. Surface client-half errors server-side. A malformed client bundle causes a silent
   white screen with a SyntaxError visible only in the browser console. Consider a
   server-side bundle-parse check at load and a visible error overlay on the page.
4. Validate the plugin contract at install/load time. Detecting bare export
   syntax in a client half, or an apply() that reads undeclared properties, would
   turn a total outage into a clear, actionable message.
5. Document sandbox-only symbols explicitly. harness, styles, host, fetch,
   setTimeout are available only inside sandboxed dynamic packages. Third-party
   plugin authors following existing examples will otherwise assume they exist.
6. Make the crash loop self-evident. systemctl is-active returning active while
   the unit loops is actively misleading. Consider exposing restart count / last boot
   error via dsh status output.

---

9. Appendix — raw evidence

Full journal excerpt, 12:13:58, crash iterations with increasing PID:

12:13:46 dsh[920]    : mcp.server.serve_error ... error_type=CancelledError
12:13:58 dsh[46149]  : Error: dsh: plugin tree failed to load: ... cannot get property "timeout" without inject
12:14:26 dsh[46244]  : Error: dsh: plugin tree failed to load: ... cannot get property "timeout" without inject
12:24:06 dsh[50252]  : Error: dsh: plugin tree failed to load: ... harness is not defined
12:24:11 dsh[50370]  : [ocgo-guard] timer 服务: 不可用（首字看门狗已关闭，其余统计照常）
12:24:18 dsh[50370]  : Error: dsh: plugin tree failed to load: ... harness is not defined
...
12:33:06             : (post-fix restart)
12:45:38             : systemctl show dsh-web -p NRestarts → 0

Aggregate counts over the journal:

Pattern	Occurrences
without inject	195
harness is not defined	55
plugin tree failed to load	50
Unexpected token (server-side)	0

The 0 on the last row is itself the finding: the most user-visible symptom
(the white screen) leaves no server-side trace whatsoever.

Redaction note

Paths, hostnames, and access tokens have been genericized. dsh URLs embed a token —
they must not be pasted into issues, chats, or screenshots.

[moonquake2004]

你这条报告的核心诉求我完全同意，而且它正是"诊断工具必须能独立于宿主运行"的理由：出故障的路径恰好是唯一的诊断入口。我们为此做了一个宿主之外的独立 CLI（诊断不加载 profile、不依赖 dsh 能启动），所以先把"我们抓得到什么、抓不到什么"讲清楚，再问一个能让我们补上缺口的问题。

抓得到的（--boot-check）：逐条 entry 在子进程里真的 import，并把失败归类——缺导出（does not provide an export named …）、依赖没装全（ERR_MODULE_NOT_FOUND）、原生 ABI 失配（NODE_MODULE_VERSION）、模块格式（ERR_PACKAGE_PATH_NOT_EXPORTED/ERR_REQUIRE_ESM）、顶层卡死（超时）。命中后 --quarantine <包名> 把它移出启动列表（先备份、不动包文件、可 --unquarantine 放回），宿主先能起来。

抓不到的（必须明说）：你的失败发生在 apply() 内部——模块能 import，装载链是在应用阶段被中断的。我们的探针只做到 import，因此你的 dsh-ocgo-guard 在我们这里会显示为 loadable。今天它抓不到这一类，我不想用"覆盖面"把它说得比实际好。

但你那条观察已经改掉我们一处错误的信号：你说"端口绑着、systemd active、页面永远打不开"，而我们的端口检查此前对"端口被 dsh 实例占用"直接判 正常 —— 那正好给出与你相反的结论。现在它会额外发一次 HTTP：绑着但无应答就报失败，并说明这与"插件在 apply() 抛错 → 装载链中断 → 进程退出 → 被 systemd 重启"的循环一致（dsh-doctor@0.4.31）。端口占用不等于服务健康，这条得谢谢你。

一个能让我们补缺口的问题：那两条 host 侧致命规则具体是什么？我们的客户端侧已经有两项静态检查（client 产物语法、client require 与宿主模块表比对），你第三条"client-side 且静默白屏"听起来正好落在那里——如果能说出三条规则各自是什么，我可以明确回答哪几条能离线判、哪几条不能；能判的我就加检查并配回归用例（比如"声明了某字段但宿主不提供"这类完全可以离线判）。

另外关于 apply() 期故障：理论上可以进一步用最小伪造 ctx 调用 apply() 看它是否抛错，但那意味着用编造的上下文执行第三方代码，结果会很吵（很多插件需要真实 ctx 才能跑），所以我倾向只把"同步抛出"记为一条低置信提示而不是判定。如果你觉得这类在你遇到的事故里占多数，我就按这个范围做；否则更值得做的是把上面那三条规则变成静态判据。

[yxloveql]

先谢你那句"端口占用不等于服务健康"——那也是我这边最贵的一课：systemctl is-active 返回 active、3080 在监听、而我据此排除了端口，转头去查 winnat，浪费了最久的一段。dsh-doctor 现在多发一次 HTTP 探针，正是唯一能在"服务看起来活着"时把它判死的手段。

下面直接回答你的问题。先给三条规则，再给一条你没提到但同样致命的第四条，最后说清楚我这边的证据边界。

---

一、三条规则，以及各自的失败形态

规则 1（host，致命）：不能在 apply() 里读取未在 inject 中声明的服务属性

原始代码在 lib/index.js:140 读取了一个未声明的属性，cordis 的 Proxy 直接抛错：

Error: cannot get property "timeout" without inject
    at .../dsh-ocgo-guard/lib/index.js:140:22
    at new apply (.../dsh-ocgo-guard/lib/index.js:142:7)
    at Fiber.execute (.../cordis/lib/index.js:1067:24)

关键点：cordis 对未声明属性不是返回 undefined，是抛异常。所以 if (ctx.foo) 这种"防御性写法"本身就会炸——它不是一个可以靠真值判断绕过的 undefined。

timeout 是属性名（不是服务名）。之所以特别容易被误用：本 profile 没有装 cordis-plugin-timer，timer 服务整个不存在，作者大概是想做个兜底，结果撞在 Proxy 上。

规则 2（host，致命，且与规则 1 独立）：不能在普通 cordis 插件里引用 harness 全局

ReferenceError: harness is not defined
    at Fiber.<anonymous> (.../dsh-ocgo-guard/lib/index.js:230:30)
    at new apply (.../dsh-ocgo-guard/lib/index.js:230:9)

harness 是沙箱动态包专属的闭包符号，从 node_modules 加载的普通插件里没有这个全局。

两个细节值得你注意：

• 这两条是先后两个独立错误，不是同时发生的。12:13:58 先报规则 1；我修掉之后，12:24:06 才暴露出规则 2。日志计数：规则 1 出现 195 次，规则 2 出现 55 次。如果只按"一个插件一处错"去建模，会漏掉第二处。
• harness.handle && harness.handle(...) 这种写法挡不住。裸标识符在 && 短路之前就被解析了，ReferenceError 照样抛。必须写成 typeof harness !== 'undefined'，而且判断要放在前面。

规则 3（client，静默白屏）：client 半边不能是裸 ESM

第三方 client bundle 必须是 __ModuleLoader__.load({ id, factory }) 的 CJS 工厂，写成 export 会让整个 bundle 解析失败：

Uncaught SyntaxError: Unexpected token 'export'

这条正是你说的"落在你们已有静态检查里"的那个。而它最要命的地方是：服务端日志里出现 0 次。 我核过整份 journal，Unexpected token 计数是 0——它只存在于浏览器 console。服务端健康、端口在听、页面永远空白，且服务端零痕迹。这一条的信息不对称是这次事故里最难的部分。

---

二、第四条（你没提到，但同类）：host / styles 等沙箱专属闭包在 bundle 里不存在

修规则 3 的过程中撞上的：client 半边用了 ctx.get('host') 和 styles。

在常驻 bundle 模式下，客户端拿不到 host 服务——沙箱宿主专属符号（host.call / harness / styles）在 bundle 里不存在，报 styles is not defined。

（说明：以上关于"客户端到底 provide 哪些服务"的表述，来自我修复时留下的代码注释，我没有独立验证过，只确证了 styles is not defined 这个报错本身。你如果需要，我可以回去把 client-runtime 的服务表拉出来核对。）

我最后改成自插 <style> + 走 HTTP，参照的是 dsh-dream-skin / dsh-better-sidebar 的成熟做法。

这条和规则 2 是同一个根因的两个面：harness（host 侧）和 host/styles（client 侧）都是"沙箱动态包才有的东西"，但在两种半边、两种加载路径下各炸一次。如果只把它当成两件孤立的事，会各修一遍。建议文档里把这句话显式写出来：沙箱专属符号在普通插件（host 与 client 两侧）一律不存在。

---

三、按你的判据分类：哪几条能离线判

规则	能否离线静态判定	我的看法
1. 未声明 inject 就读属性	能，但需要 AST 分析	要解析 apply(ctx) 的函数体，列出所有 ctx.<prop> 与 ctx.get('<name>')，再和返回对象上的 inject 数组比对。误报点：ctx 被改名、解构、传给辅助函数后间接访问。建议按"高置信、可加白名单"来做
2. 裸 harness 全局	能，而且最划算	纯词法：作用域内未声明就用 harness / styles 等已知沙箱符号 → 直接报。没有动态性，几乎零误报。这条我强烈建议加
3. client 产物是裸 ESM	能，且你们已经有了	语法层即可判 export / import 出现在 client bundle 顶层
4. client 依赖宿主不提供的服务	能（就是你说的"声明了某字段但宿主不提供"）	把 ctx.get(x) / inject 里的名字与宿主模块表比对。同样几乎零误报

结论：四条里有三条完全可离线判（2、3、4），规则 1 可判但需要容忍一定的误报。

---

四、关于"用最小伪造 ctx 调用 apply()"

我建议不要做成判定项，但可以留作低置信提示——理由和你担心的完全一致，而且我有具体的反例支撑：

规则 1 和规则 2 都是同步抛出，所以伪造 ctx 理论上能抓到。但这次事故里，apply() 还做了大量真实工作：读配置、注册 ctx.effect、挂 llm/stream 与 agent/request 拦截器、尝试 ctx.get('tools')、注册工具。用伪造 ctx 跑，这些会大量误炸——噪音会淹没真信号，而且维护者会很快学会忽略它。

但有一个限定条件值得考虑：如果只做"语法上可静态识别的违规访问"，而不是真去执行代码，就同时拿到了两边的好处——规则 2 和 4 本质上是静态可判的，不需要跑。

所以我的排序是：

1. 先做规则 2、3、4 的静态判据（零误报、覆盖我这次事故三条中的两条）
2. 再做规则 1 的 AST 判据（带白名单）
3. "同步抛出"作为提示：可以保留，但标注为低置信、且明确写"仅当 apply() 没有真实副作用时才可信"

最后一句话给你做取舍参考：我这次事故里，host 侧两条（1、2）都是同步抛出，client 侧两条（3、4）都是静态可判。 也就是说——如果只做静态判据，这次四条里有两条能抓到；如果加上 apply() 探针，能到三条；规则 1 那条恰好是两者都需要一点才稳的那类。

---

五、一个必须说明的证据边界

我不希望你按一个我无法证实的模型去做实现，所以这点必须讲清楚：

我手上没有事故当时的原始插件源码了。 崩溃发生在 12:13，而所有保留的备份（bak-1225 及之后）都是 12:23 以后我已经开始修的中间态。原始坏版本被覆盖了。

上面关于三条规则的描述，全部来自事故当时抓取并已存档的 journal 原始栈（行号、错误文本、出现次数都是实录，报告正文里有全文），不是事后从代码反推的。但"第 140 行那一句原文具体怎么写"这个粒度，我给不出，只能给出它读取的属性名是 timeout。

另外，--boot-check 只做到 import 这点你讲得很实在。补充一个数据点供你判断优先级：我这次的失败 100% 在 apply() 内，import 阶段是干净的——你的探针在我这里会显示 loadable，这一点你预料得没错。所以如果 --boot-check 的失败归类里有"apply 期"这一类，它在真实事故里的命中率可能比 import 类更低。

[moonquake2004]

这份回复把"能不能离线判"从猜测变成了工程清单，谢谢——尤其你给的四条分类与我担心的完全一致。按你的排序，我把零误报的那几条做出来了（dsh-doctor@0.4.32），并有一个你的评估需要修正的数据点。

已实现

• 规则 2（裸 harness，host 侧）与规则 4（styles / ctx.get('host')，client 侧）→ 合并为 P21，按 error 定级。 理由是你说它致命且我核对了机制：它在 apply() 内同步抛出 → cordis 中断装载链 → 整棵 Web UI 不可用。你那条"harness.handle && … 挡不住，裸标识符在短路之前就被解析"我也写进了检查的修复指引里——这正是"看起来像防御性写法、实际仍会炸"的坑。
• 规则 3（client 产物写成裸 ESM）→ P20，按 warn 定级。 你说它落在我们已有检查里，这里要更正一下：我们既有的 client 语法检查用的是 node --check，而 export 是合法 ESM 语法，能通过解析——失败的时机是 __ModuleLoader__ 工厂加载它。所以那条检查抓不到你这一条，得单独判"是否有工厂 + 顶层是否 ESM"。这条缺口是你这份报告暴露出来的。
• 规则 1（未声明 inject 就读属性）暂未做。 与你的判断一致：需要解析 apply(ctx) 函数体、列出 ctx.<prop> 与 ctx.get()，再与返回对象的 inject 比对，误报点（ctx 改名/解构/传参间接访问）需要白名单。我倾向按"高置信 + 可白名单"做，但想先确认一件事：报错文本 cannot get property "timeout" without inject 本身是否可离线复现（即不执行插件、只做静态比对）。如果宿主没有暴露可查询的"某 entry 的 inject 声明"，我就只能从 patch/源码里读 inject 数组。你要是知道它写在哪个字段，我据此实现会更稳。

一个需要修正的评估：你说的"纯词法、几乎零误报"只在两轮治理之后成立。 我先按最直接的词法实现，结果在真实 profile 上连撞两次误报：

1. 注释：//#region styles——打包器区域标记，6 处命中全是假的；
2. 加注释剥离后，字符串："deepseek-harness"、/api/harness/connector/stream、"office-harness.v1"——3 处命中全是假的。

最终判据是：剥注释 + 剥字符串字面量 + 要求符号处于代码位置（后跟 ./[/(，真正使用一个全局必然如此）+ 文件本地声明了同名变量就不算 + 有 typeof 守卫则只记提示。这样在 8 个 host 入口 + 8 个 client 产物上零误报，而你给的那两类样例仍能被抓出。之所以反馈这一点：任何人照"纯词法"三个字去实现，都会先收到一批假警报——误报健康插件比不报更糟，这条正是我们两边都会同意的。

关于你的证据边界：明确说"原始源码已被覆盖、规则描述全部来自当时存档的 journal 栈"——这是正确的做法，也让我的实现不受影响：P20/P21 都锚在错误文本与语法形态上（Unexpected token 'export'、裸标识符引用），不依赖你第 140 行的具体写法。你补的"host 侧两条都是同步抛出、client 侧两条都是静态可判"这个分布，正好解释了为什么我这次的排序与你的一致。

发布：dsh-doctor@0.4.31（端口占用≠服务健康，你那句"最贵的一课"）、0.4.32（P20/P21）。测试 165 全绿。规则 1 那条，等你确认 inject 声明可从哪里读，我就动手。