the code-runtime seam owns portable-identifier exclusions
code-runtime seam 拥有可移植标识符排除集
The code-runtime seam promises that a binding-namespace list valid on one backend is valid on every backend, so a Code Mode consumer can hand the same bindings to any registered runtime without knowing its language. The first backend, `dsh-code-runtime-worker-thread`, privately owned the identifier rules that enforce part of that promise: an `IDENTIFIER` regex that allowed the JS-only `$`, a `RESERVED_WORDS` set hold
English
Problem
The code-runtime seam promises that a binding-namespace list valid on one backend is valid on every backend, so a Code Mode consumer can hand the same bindings to any registered runtime without knowing its language. The first backend, dsh-code-runtime-worker-thread, privately owned the identifier rules that enforce part of that promise: an IDENTIFIER regex that allowed the JS-only $, a RESERVED_WORDS set holding only ECMAScript keywords, and a RESERVED_ERROR_PROPERTIES set of three JS Error slots. Those rules described the worker's own language, not the seam's portability contract.
A second backend written against a different language (CPython) would either re-declare its own rules — letting lambda pass the worker and fail Python, or $tools pass the worker and fail every non-JS backend — or import the worker's, inverting the dependency so a Service Provider reached into a sibling Service Provider. Neither keeps the portability promise real: it would hold only for the backend a caller happened to test against.
Decision
The Service Definition package (@deepseek-ai/dsh-code-runtime) exports the portable-identifier exclusion contract as four named constants, and every Service Provider imports them rather than re-declaring:
PORTABLE_RESERVED_WORDS— the union of ECMAScript and Python reserved words. A namespace global or error-class name matching any is refused on all backends, solambdais refused even though it is a legal JS parameter name. Adding a language widens this union, which is a deliberate breaking review of existing binding names.RESERVED_BINDING_GLOBALS— globals some backend owns in the program's namespace:console(the worker's log capture),__dsh_main__/__builtins__/__name__(the Python bootstrap's wrapper and seeded module globals), and__debug__(not a seeded slot but a CPython compile-time constant that rejects assignment, so an injected global under that name is unreachable — the same portability split by a different mechanism). Refused everywhere so a namespace list cannot pick a name that works on one backend and collides on another.RESERVED_ERROR_MEMBERS— error-member names every backend refuses: the JSErrorslots (name,message,stack) and Python's exception-protocol members (args,with_traceback,add_note).DUNDER_MEMBER— the dunder-form regex (__x__, non-empty middle), refused as an error member wholesale because several are constrained CPython descriptors whose exact set is an interpreter-version detail.
The Service Definition also narrows the portable identifier subset to [A-Za-z_][A-Za-z0-9_]* (documented on CodeBindingNamespace.global and CodeBindingErrorClass), dropping the JS-only $. The worker consumes the shared constants directly under their exported names — PORTABLE_RESERVED_WORDS for both binding-global and error-class names, RESERVED_BINDING_GLOBALS for backend-owned slots, RESERVED_ERROR_MEMBERS plus DUNDER_MEMBER for error members — with no local re-alias; its IDENTIFIER regex loses $.
The constants live in the Service Definition even though the worker is the only shipped backend: the whole point is that the contract is language-agnostic and owned above any single language. A Service Provider that violated it would be the bug, and the shared set is where a reviewer looks to see what "portable" means.
Scope
This decision delivers only the Service Definition extension and the worker's adoption of it. The py-types renderer and Code Mode language dispatch are owned by the language-dispatch note; a Python backend does not exist yet. The Service Definition README keeps its worker-only wording for that reason: linking to a dsh-code-runtime-python README that does not exist would break the dead-link gate.
RESERVED_BINDING_GLOBALS encodes the Python bootstrap's concrete design ahead of the backend itself: it seeds exactly __builtins__/__name__ and wraps the program under __dsh_main__. A Python backend that seeds any additional module global (__doc__, __loader__, __spec__, __file__, __package__, …) MUST widen this set in the same change, exactly as adding a language widens PORTABLE_RESERVED_WORDS — a name the bootstrap seeds but the set omits is the portability split this contract exists to prevent.
Alternatives considered
Each backend declares its own exclusions. Rejected: it makes the portability promise per-backend. A binding list the caller tested on the worker could be refused by Python, which is exactly the split the seam exists to prevent.
The Python backend imports the worker's constants. Rejected: it inverts the dependency — the seam's Service Providers would reach into a sibling implementation for a contract neither owns. The contract belongs above both, at the seam.
Keep $ in the portable identifier subset. Rejected: $ is JS-only spelling. Allowing it would let $tools pass the worker and fail every non-JS backend, breaking portability for a purely cosmetic gain.
Consequences
Bought: one place — the Service Definition package — defines what a portable binding name is, and every backend enforces the same contract by import. A namespace list valid on one backend is valid on all, verifiably, not by coincidence of which backend the caller tested.
Cost: existing worker callers using a $-containing global now fail identifier validation. Under the pre-release stance this is a corrected foundation, not a compatibility break to shim. The worker's Service Definition misuse tests gain cases for $tools, Python exception members (args), dunders (__dict__), and a Python-owned global (__dsh_main__), proving the shared set is enforced from the worker side.
中文
Problem
code-runtime seam 承诺：在一个后端上有效的绑定命名空间列表，在每个后端上都有效，因此 Code Mode 消费方可以把同一组绑定交给任何已注册的运行时，而不必知道它的语言。首个后端 dsh-code-runtime-worker-thread 私自拥有了执行这项承诺一部分的标识符规则：一个允许 JS 专有 $ 的 IDENTIFIER 正则、一个只含 ECMAScript 关键字的 RESERVED_WORDS 集合，以及一个含三个 JS Error 槽位的 RESERVED_ERROR_PROPERTIES 集合。这些规则描述的是 worker 自身的语言，而非 seam 的可移植性约定。
一个针对不同语言（CPython）编写的第二后端，要么重新声明自己的规则——让 lambda 通过 worker 却在 Python 上失败，或让 $tools 通过 worker 却在每个非 JS 后端上失败——要么导入 worker 的规则，从而反转依赖，使一个 Service Provider 伸手进入另一个兄弟 Service Provider。二者都无法让可移植承诺成真：它只对调用方恰好测试过的那个后端成立。
Decision
Service Definition 包（@deepseek-ai/dsh-code-runtime）以四个具名常量导出可移植标识符排除约定，每个 Service Provider 导入它们而非重新声明：
PORTABLE_RESERVED_WORDS——ECMAScript 与 Python 保留字的联集。任何命名空间 global 或 error-class 名称匹配其中之一，都在所有后端上被拒绝，因此lambda即便是合法的 JS 参数名也被拒绝。新增一门语言即扩宽此联集，这是对现有绑定名称的一次有意的破坏性复审。RESERVED_BINDING_GLOBALS——某个后端在程序命名空间中拥有的 global：console（worker 的日志捕获）、__dsh_main__/__builtins__/__name__（Python bootstrap 的包装器与预置模块 global），以及__debug__（不是 seed 的槽位，而是 CPython 编译期常量，赋值会被拒，故以该名注入的 global 不可达——同一种可移植性分裂，只是机制不同）。在所有后端上被拒绝，使命名空间列表无法选到一个在某后端能用、在另一后端冲突的名称。RESERVED_ERROR_MEMBERS——每个后端都拒绝的 error-member 名称：JSError槽位（name、message、stack）与 Python 异常协议成员（args、with_traceback、add_note）。DUNDER_MEMBER——dunder 形式正则（__x__，非空中缀），作为 error member 被整体拒绝，因为其中若干是受约束的 CPython 描述符，其确切集合是解释器版本细节。
Service Definition 同时把可移植标识符子集收窄为 [A-Za-z_][A-Za-z0-9_]*（记录在 CodeBindingNamespace.global 与 CodeBindingErrorClass 上），去掉 JS 专有的 $。worker 直接以这些常量的导出名称消费它们——binding-global 与 error-class 名称用 PORTABLE_RESERVED_WORDS、后端拥有槽位用 RESERVED_BINDING_GLOBALS、error member 用 RESERVED_ERROR_MEMBERS 加 DUNDER_MEMBER——不再本地起别名；其 IDENTIFIER 正则去掉 $。
尽管 worker 是唯一已交付的后端，这些常量仍置于 Service Definition：要点正是该约定与语言无关，且由高于任何单一语言的层级拥有。违反它的 Service Provider 才是 bug，而共享集合正是复审者查看「可移植」含义的地方。
Scope
本决策只交付 Service Definition 扩展与 worker 对它的采用。py-types 渲染器与 Code Mode 的语言分发归语言分发 note 所有；Python 后端尚不存在。Service Definition README 因此保留仅描述 worker 的措辞：链接到一个不存在的 dsh-code-runtime-python README 会破坏死链 gate。
RESERVED_BINDING_GLOBALS 先于后端本身编码了 Python bootstrap 的具体设计：它恰好 seed __builtins__/__name__，并把程序包装在 __dsh_main__ 之下。任何 seed 额外模块 global（__doc__、__loader__、__spec__、__file__、__package__ 等）的 Python 后端必须在同一改动中扩宽此集合，正如新增一门语言即扩宽 PORTABLE_RESERVED_WORDS——bootstrap 会 seed 却不在集合中的名称，正是本约定要防止的可移植性分裂。
Alternatives considered
每个后端声明自己的排除集。 拒绝：这让可移植承诺变成逐后端成立。调用方在 worker 上测过的绑定列表可能被 Python 拒绝，而这正是 seam 存在要防止的分裂。
Python 后端导入 worker 的常量。 拒绝：这反转依赖——seam 的 Service Provider 会为一个二者都不拥有的约定伸手进入兄弟实现。约定属于二者之上，即 seam。
在可移植标识符子集中保留 $。 拒绝：$ 是 JS 专有拼写。允许它会让 $tools 通过 worker 却在每个非 JS 后端上失败，为纯粹表面的好处破坏可移植性。
Consequences
获得：一个地方——Service Definition 包——定义什么是可移植绑定名称，每个后端通过导入执行同一约定。在一个后端上有效的命名空间列表在所有后端上都有效，这是可验证的，而非取决于调用方测试了哪个后端的巧合。
代价：现有使用含 $ global 的 worker 调用方现在会在标识符校验时失败。在预发布立场下这是对基础设计的一次纠正，而非需要 shim 的兼容性破坏。worker 的 Service Definition misuse 测试新增了 $tools、Python 异常成员（args）、dunder（__dict__）与一个 Python 拥有的 global（__dsh_main__）等用例，从 worker 侧证明共享集合被执行。