[Bug 修复] 第三方插件的 Typert Remote 端点全部返回 404（协议包被加载成两份实例）

[fishOfOUC]

本仓库的 Issues 与 Pull Requests 均已关闭，故以 Discussion 形式反馈。修复补丁见文末的 fork 分支链接，供维护者参考采纳。

装在 profile 里的第三方插件导出的 Typert Remote 方法全部不可用：所有 /api/<namespace>/<method> 请求返回 HTTP 404，而提供这些方法的 Service 已挂载且处于 ACTIVE。

复现、预期与验收

• 复现步骤：
  1. 在一个 dsh profile 里安装一个导出 Typert Remote 方法的第三方包（例如 @daweifu/capability-menu-web：其 CapabilityPolicyGateway 继承 TypertRemoteService，用 @Remote 装饰 getConfig / updateConfig / classifyAll，服务键 capabilityPolicyGateway，wire namespace capabilityPolicy）
  2. 从工作区源码启动宿主（dsh web）
  3. 客户端调用 /api/capabilityPolicy/classifyAll
• 实际结果：HTTP 404。运行时诊断表明服务本身是好的：impl[capabilityPolicyGateway] state=ACTIVE、typertRemote.namespace=capabilityPolicy，但网关的 collectSrcClaims() 不为它认领任何端点。同一宿主上工作区内的包（如 pluginInventory）返回 200。
• 预期结果：端点被认领，请求正常返回；第三方包与工作区内的包行为一致。
• 环境：Windows 11 / Node v24.19.0 / 宿主从工作区源码启动（tsx ESM），profile 里安装的包走 node_modules 解析。
• 验收条件：
  1. 对同一个 Service 实例，用协议包的任一副本调用 remoteMethods()，都能读到另一副本由 Remote 装饰器写入的标记
  2. 上述跨副本场景下 /api/capabilityPolicy/classifyAll 返回 200 而非 404

根因

@deepseek-ai/dsh-typert-protocol 在一次运行中被加载成两个模块实例：宿主（工作区源码模式）解析到 packages/typert/protocol/src/index.ts，而装在 profile node_modules 里的第三方包解析到包 exports 的 ./lib/index.js。

Remote 装饰器通过 mark() 把方法标记写进一张模块私有的 WeakMap（packages/typert/protocol/src/index.ts，修改前 L155），remoteMethods() 再从这张表读。两份实例 = 两张互不相通的表，于是网关的 collectSrcClaims()（packages/api/gateway/src/index.ts L279-294）对第三方服务读到空方法列表，不认领任何端点。

一个排查陷阱：import.meta.resolve 对两个导入方都返回 src/index.ts，但两个模块对象并不相同 —— 解析路径不能作为模块实例同一性的证据。

修复

把标记表挂到 globalThis 的 Symbol.for('dsh.typert.remoteMarkers') 上，使所有副本共享一张表（与 vendor/cordis/src/context.ts 用 Symbol.for('cordis.is') 跨副本的做法一致）。标记仍以 prototype 为键保存在 WeakMap 中，因此不会在第三方类上新增属性，条目随其所属类消亡。

补丁（1 个提交，含跨副本回归测试与 Agent Note）：
https://github.com/fishOfOUC/deepseek-harness/tree/fix/typert-remote-marker-table-global

由于本仓库不接受 PR，未能直接提交，在此附上根因与补丁位置供参考。

[fishOfOUC]

补充：这个问题在上游已经有独立修复，原帖的分析针对的是旧代码，仅供追溯。

我最初反馈时基于的提交是 cd5ef81481，当时 remoteMethods() 读取的是一张模块私有的 WeakMap（packages/typert/protocol/src/index.ts），于是出现了原帖描述的「两份包副本各持一张表、互不可见」。

拉取最新 master（0a53fb55be）后可以看到，标记存储已被重写为挂在 prototype 上的非枚举、版本化描述符：

const REMOTE_METHOD_DESCRIPTOR = '@deepseek-ai/dsh-typert-protocol/remote-methods'

mark() 用 Object.defineProperty(prototype, KEY, ...) 写入，remoteMethods() 用 Object.getOwnPropertyDescriptor(prototype, KEY) 读取。因为键是字符串常量（每份副本里取值相同），而 prototype 是同一个对象，两份副本天然共享同一份标记 —— 原帖的跨副本不可见问题从结构上不再存在。配套用例 it('stores a non-enumerable versioned marker descriptor on the prototype') 也把这个行为钉住了（断言 Reflect.ownKeys(prototype) 含该键，而 Object.keys(prototype) 为空）。

相比之下，我原帖附的补丁（把标记表挂到 globalThis 的 Symbol.for('dsh.typert.remoteMarkers')）只是权宜做法：它引入一个进程级全局键，而字符串键方案不引入任何全局状态，还带 version 字段便于后续演进。以 master 现有实现为准即可，不必采纳我的补丁。

原帖正文与 fork 分支（fishOfOUC/deepseek-harness@fix/typert-remote-marker-table-global）保留，作为对 cd5ef81481 及更早代码的追溯与临时修复参考。

最后一句排查提醒仍然成立：模块解析路径相同 ≠ 模块实例相同。判断「同一个包是否被加载了多份」必须比对模块对象本身，不能只信 import.meta.resolve 的返回值 —— 这一点我在定位过程中踩过坑。