Proposal: recognize the published Typert protocol in external plugins

[leecky]

Context

OpenBKN is an open business knowledge-network platform. Its independently published DeepSeek Harness bundle lets a business user sign in to OpenBKN, bind one DSH session to one authorized knowledge network, and analyze that network through scoped platform OSDK operations.

The bundle needs a typed Host-to-Client Remote only for safe control-plane state: OpenBKN authentication status and session-scoped network selection. The browser never receives a platform token, SQL execution entry point, or unrestricted network capability.

Problem

A normal external package imports Remote, TypertRemoteService, and related declarations from the published @deepseek-ai/dsh-typert-protocol package in node_modules.

Today, WorkspaceTypertGenerator.isTypeMetaSymbol() recognizes that metadata only when the declaration belongs to a registered DSH workspace package or an ambient declaration. An independently published plugin matches neither condition, so its Remote methods are not discovered and no Remote artifact is generated.

This appears to be the same external-package boundary described in:

• Typert generator never recognizes @Remote from an npm-installed protocol, so an out-of-tree plugin gets no Remote layer at all #2981 — external plugin protocol declarations are not recognized
• WorkspaceTypertGenerator silently emits no artifacts for an out-of-workspace package #4679 — external package discovery and generation
• [Bug 修复] 第三方插件的 Typert Remote 端点全部返回 404（协议包被加载成两份实例） #5146 — third-party plugin Remote endpoint behavior
• Remote contribution registry for out-of-tree Host plugins #3167 — broader external Remote contribution discussion

Narrow proposal

Keep the existing workspace and ambient-declaration checks. Add one exact identity check using the existing externalModuleIdentityForFile() helper: recognize a declaration only when its resolved external package name is exactly @deepseek-ai/dsh-typert-protocol.

This is deliberately not a symbol-name fallback. An unrelated npm package that exports a decorator named Remote must remain unrecognized.

Candidate patch and validation

I prepared and pushed a small, self-contained patch:

• Fork branch: leecky:fix/third-party-remote-compat
• Commit: 105cf46

It includes:

1. A regression fixture that models a normal external node_modules/@deepseek-ai/dsh-typert-protocol package and verifies Remote artifacts are generated.
2. A negative fixture proving an unrelated external lookalike package is not treated as the protocol.
3. An English/Chinese Agent Note explaining scope, alternatives, acceptance criteria, and risks.

Validation completed:

• 53 focused Typert tests
• pnpm run typecheck
• Agent Note format and translation-pairing checks

The upstream repository has pull-request creation disabled, so I am opening this Discussion to request guidance on the preferred contribution path and whether this narrow package-identity rule is acceptable.

Why this matters beyond OpenBKN

This is a general external-plugin capability. Independently published plugins often need a typed Remote for settings, authorization state, and small UI-control-plane interactions, while retaining DSH-owned rendering and keeping sensitive operations on the Host. Without generated Remote artifacts, these plugins either cannot ship as ordinary npm packages or must avoid a useful typed boundary.

I would welcome maintainer feedback on the patch shape and the appropriate route for contribution.