[ds-spec 2.4 review] 重构落地前应补齐的确定性、安全与扩展契约

[yqzhishen]

审查范围

审查基线：docs/ds-spec-2.4.md @ 2a5a6e3。

本 issue 只讨论 spec 自身的矛盾、歧义和缺失的协议边界。refactor 是待重构的旧版本；旧代码尚未实现 2.4 不构成这里的风险，也不以旧实现作为规范真值。

2.4 把 interface、variant、开放贡献类别和统一引用拆开，方向比 2.3 清楚很多。但目前仍有若干地方会让两个“严格按文档实现”的 Installer / Loader / Executor 得到不同结果。建议在新架构冻结前至少解决下列 P0 项。

P0：建议在 2.4 冻结前解决

1. required: false 与“所有依赖都必须可加载”直接矛盾

描述文件定义了 dependencies[].required，默认 true，加载规则却规定 “当且仅当所有依赖项都能被加载”时 Package 才能加载。

最小反例：

{
  "dependencies": [
    { "id": "gpu-accel", "version": "1.0", "required": false }
  ]
}

机器未安装 gpu-accel 时，一个 Loader 可以依据 required:false 继续，另一个可以依据“所有依赖”拒绝，二者都符合原文。若模块又无条件 ref 到该依赖，跳过依赖后仍会在 Ready 阶段失败。

建议：

• 给 missing、present but incompatible、load/init failed 三种情况分别规定 required/optional 的结果；
• 明确 optional 依赖是否参与版本冲突求解；
• 为 import 增加 optional / feature gate / fallback，或明确禁止对 optional 依赖作无条件引用；
• 将“所有依赖”改为“所有 required 依赖”，并说明 optional 依赖失败是否只产生诊断。

2. 版本文法、依赖求解和引用绑定没有确定算法

当前字段说明只给出 x.y[.z.w]，引用 ABNF 又使用了一个未定义的 version production。因此至少这些问题没有唯一答案：

• 是否允许一段或三段版本；1.0、1.0.0、1.0.0.0 是否相等；
• 是否允许前导零，各分量上限和溢出行为是什么；
• compatVersion <= version 是否是合法清单必须满足的不变量；
• dependencies[].version 是最低兼容基线，而 ref 中的 =version 是精确安装版本、兼容基线，还是二次求解条件；
• dependency 写 bar >= 1.0、ref 写 bar=2.0:inference/x 时应报冲突、提升约束，还是加载两个实例；
• 多个搜索根或同一根中有多个兼容版本时，先按路径优先还是先取最高版本；
• diamond dependency、重复依赖、自依赖、环和同 ID 多版本是否允许并存。

“简单方案”只说依次遍历路径并取找到的兼容依赖，仍不足以让结果可复现。

建议给出完整 ABNF、规范化与比较规则，并提供一段规范性 resolver 伪代码。ref 应绑定本次依赖求解得到的实例，而不是再次做全局搜索；求解结果最好能输出包含实际版本、路径/来源和内容摘要的 resolution graph/lock。

3. compatVersion 没有定义“兼容”必须保持什么

当前算法只用 version >= requested && compatVersion <= requested 判断候选是否兼容，却没有定义 Package 的兼容性承诺覆盖哪些公开表面。

例如 bar@1.1 可以声称兼容 1.0，同时把 inference/pitch 的 interface 或 Level 换掉、删除某个 export，甚至复用同一模块 ID 表示另一件事。依赖方仍会被允许绑定到它，但原有 options 将按另一套契约解释。

建议明确兼容区间内至少要保持：公开 category/module ID、模块的 interface/Level 兼容关系、exports/options schema，以及可观察的运行时契约。Import 也应能声明 expected interface/level/capabilities，并在 Ready 前验证；不满足这些不变量的版本必须提升 compatVersion。

4. .dspk 的安全解包与路径封闭完全未规定

规范目前只说 .dspk 是 ZIP，声明路径相对声明文件解析，安装则只是“在某个目录中解压”。这会把安全关键行为全部留给实现猜测：

• ZIP entry 的 ..、绝对路径、盘符/UNC、反斜杠；
• symlink/junction 及“先建链接、再写链接下文件”的逃逸；
• 重复 desc.json、大小写或 Unicode 归一化后碰撞；
• 特殊文件、超长路径、zip bomb、伪造 size header、过多文件；
• 模块声明里的 ../、绝对路径，以及 ONNX external data 等二级引用逃出 Package root。

建议增加 normative DSPK profile：只允许 package-root 内的 regular files；拒绝绝对/父级/链接/特殊条目和归一化后冲突；根部恰有一份 desc.json；限制单文件/总解压字节、文件数、压缩比、路径长度、JSON 大小/深度；流式解压时再次计数；先写同文件系统 staging，完整验证后原子提交，失败整包清理。所有直接和模型格式内部的间接路径都必须在 canonicalize 后仍位于 package root。

另外应明确信任模型：若 id + version 被当作依赖身份，建议至少支持内容摘要锁定；签名由本规范承担还是由单独 distribution profile 承担，也应明确。

5. 推理任务只有方法名，没有可验证的生命周期与并发契约

initialize/start/startAsync/stop/state/result 没有定义：

• 合法状态与状态转移，初始化/失败/取消后能否复用；
• 同一实例是 single-flight、多并发还是有界排队，队列满时如何背压；
• startAsync 的 callback 线程、是否恰好一次、是否允许重入、对象销毁时如何处理；
• start 提交失败与任务运行失败的错误通道及优先级；
• result 何时可读、由谁持有、下一次 start 是否覆盖；
• stop 与自然完成竞态时的 terminal state，以及 deadline/timeout。

“立即停止（同步）”对不可抢占的 GPU kernel 也不是可移植的保证。建议把它改成语义明确的 cooperative cancel request，并另行定义 wait until quiescent(deadline)；给出完整状态机、每个方法的前/后置条件、幂等性、线程安全级别和资源预算/背压规则。模块加载时的 Initialized/Ready 也应与每次 inference task 的 initialize 明确分开。

6. “variant 可互换”与“exports 可以不同”互相冲突

规范先要求同一契约下各 variant “输入与输出完全一致，对导入方而言可互换”，随后又允许一个 variant 支持某项功能、另一个不支持。

最小反例：同一 (interface, level) 下 A export energy，B 不 export；Singer 的 options 要求 energy。A 替换为 B 后立即失效，因此不是无条件可互换。

建议把承诺改为“共享同一 schema/调用契约”，并把实际替换判据定义成“候选 exports 满足 importer 的 capability constraints”；Ready/Validate 阶段必须执行该检查。若真正要求无条件可替换，则同一 interface/level 的 exports 必须一致。

此外，variant 私有字段与 contract 公共字段目前共处一个 configuration 对象，未来可能键冲突；可拆成 configuration.contract / configuration.variant，或规定保留命名空间和 schema composition 规则。

7. interface 契约、解释器发现和 variant 演进仍不足以互操作

文档说 (interface, level) 定义 exports/options 和运行时输入输出，但没有在本规范中定义，也没有规范性链接到不可变的 interface-level contract。仅有三元组名称，无法判定两个实现对 tensor dtype/shape、单位、错误、所有权和取消语义是否真的一致。

同时，Loader 要靠三元组选择解释器，而插件章节又说三项属性在解释器实例化前就必须可读，却只描述了由解释器“返回”这些属性，没有定义静态 descriptor/factory。相同 triple 有两个 provider 时，也没有冲突或选择规则。

最后，规范明确不为 variant 设版本，允许它在 configuration 内自行版本化。但 Loader 必须在解析 variant configuration 前按 triple 选择 provider；两个不兼容配置格式仍使用同一 triple 时，选择阶段无法协商。

建议：

• 为每个官方 (interface, level) 发布不可变、可定位的 contract/schema，覆盖 exports/options/common configuration、运行时 I/O、单位、错误和任务语义；第三方 interface 同样必须有稳定的 schema identity；
• 定义实例化前可读的 registration descriptor + factory，至少含 provider/plugin ID、宿主 ABI、支持的 triple/config-format range；
• 同 triple 多 provider 默认报歧义，或只允许显式、稳定的用户策略选择，禁止依赖扫描顺序；
• 为 variant 增加标准 configFormat，或规定任何不兼容格式变化必须更换 variant ID；
• 明确 Level 历史支持方式：一个 descriptor 可广告 level 集合，或同一 provider 分别注册多个 level，避免“精确匹配”与旧模块免重发之间没有衔接。

P1：会破坏扩展性、确定性或跨实现一致性

8. 开放贡献类别目前仍是闭世界，而且内联表示没有统一 envelope

贡献类别被定义为开放集合，但未知类别会让 Loader 拒绝整包。一个包只要增加无关的 UI metadata 类别，旧的 headless Executor 就可能连原有 inference/singer 都无法使用。

类别名又只是裸 segment，没有命名空间、schema version 或注册冲突规则；第三方都注册 language 时无法判断语义。类别自定义的 desc entry 也没有版本轴。

此外，贡献条目可以“完全内联而不指向文件”，但后文又说所有类别模块都有由框架统一解析的 interface/level/variant 公共字段。内联条目把三元组放在哪里、是否属于“模块”，没有唯一表示。

建议采用 namespaced + versioned category descriptor，并给类别/条目 requiredness：未知 required 才失败，未知 optional 可保留并忽略。统一 contribution envelope，例如 {id, path} 与 {id, descriptor} 二选一；若允许非模块贡献，应从类型系统和术语上明确区分。

9. 省略 category 的持久引用不是演进稳定的，PackageReference 与 ModuleReference 也未分型

引用允许省略 category 并搜索所有类别。:main 在只有 inference/main 时有效；Package 后来增加 singer/main，同一份旧 manifest 未改动却突然变成歧义。

通用 reference 还能只指向 Package，但 imports 的 options 只能由“被引用模块”的 interface/level 解释，因此 package-only ref 在 imports 中没有语义。显式写当前 Package ID 是否触发“必须在 dependencies 声明”并形成自依赖，也不清楚。

建议持久化 manifest 中的 ModuleReference 强制写 category，省略只留给交互式查询；将 PackageReference 与 ModuleReference 分型，imports 只接受后者；明确 self-reference 的例外与自依赖禁令。Imports 还应由 importer contract 定义本地 slot/alias、cardinality、重复 ref 和数组顺序语义。

10. 两阶段初始化与 rollback 不是闭合的事务模型

Initialized/Ready/反序 rollback 没有说明：

• “所有模块”是当前 Package 还是整个 dependency closure；
• dependency cycle 是拒绝、SCC 两阶段，还是别的规则；
• phase 内的确定顺序是什么（contributes 是 JSON object，本身没有语义顺序）；
• 并发加载同一 Package 如何去重，何时对读者原子可见；
• A/B 共用 C 时 A 失败，C 的引用和资源是否能回滚；
• 当前失败模块的半初始化资源、rollback 自己失败、重试与 unload 如何处理。

“按相反顺序”只有在先定义唯一前向顺序并记录实际完成日志后才有意义。建议给 Package 与 Module 分别定义状态机和事务边界；先做无副作用 Resolve/Parse/Validate，再 Acquire，所有 Ready 后原子 Commit；rollback 只撤销本事务新增的引用/资源，要求幂等，并保留 primary error、附加 cleanup errors。若只支持一层跨模块引用，也应说明如何检测和诊断更深的 Ready 依赖，而不是让结果取决于遍历顺序。

11. 缺少统一 JSON、标识符和 conformance profile

规范没有明确 JSON 编码、BOM/注释、重复 key、unknown key、null 与 absent、整数范围、字符串/数组/递归上限。{"$version":"1.0","$version":"999"} 在 first-wins 与 last-wins parser 中甚至会绕过不同的版本门。

建议规范性采用 RFC 8259：UTF-8，重复 object member 一律拒绝，并明确 BOM/注释、未知字段与资源上限。标识符还需规定大小写、canonical serialization、最大长度和 collision 规则；例如 Foo/foo 在不同文件系统上不应悄悄绑定到不同对象。

同时建议：

• 定义 RFC 2119/8174 风格的 MUST/SHOULD/MAY；
• 分别列出 Installer、Loader、Executor 的 conformance 要求和验证顺序；
• 发布 desc.json、公共 module envelope 及官方 category/interface 的机器可读 schema；
• 提供正反 test corpus：版本/引用、依赖图、重复键/深度、恶意 ZIP、生命周期/取消竞态、大小写/Unicode/跨平台路径。

12. RFC 4647 Lookup 的转述不完整，路径型多语言字段也没有落到具体字段

多语言章节只描述单个偏好标签逐段右删。但 RFC 4647 Lookup 的输入通常是有序 language priority list，并且遇到 singleton extension/private-use 时要连同相邻尾段处理，不能产生 de-DE-x 这类中间候选。*、非法/废弃 tag 和 canonicalization 也未说明。

匹配又声明大小写不敏感，因此 JSON 同时出现 zh-CN 与 ZH-cn 时两键语义相同，当前没有拒绝或胜者规则。

建议直接规范性引用 RFC 4647 §3.4 的完整算法：按顺序处理 preference list，整张列表失败后才取 _；加载时校验 BCP 47 tag，并拒绝 case-fold/canonicalize 后的重复键；发布含 extension/private-use/重复大小写键的 golden vectors。

另外，“多语言字段的值是文件路径时” 目前没有对应到任何明确声明为“多语言路径”的标准字段。请逐字段说明 readme、avatar、background、demoAudio 等究竟是普通路径还是本地化路径，并让每个本地化路径都服从第 4 条的 package-root confinement。

示例与编辑性问题

• Singer 示例引用的是 bar/pitch=1.0.0.0:inference/pitch，而 desc 示例依赖的是 bar；如果它们意在组成一份连续示例，则违反“外部 Package ID 必须在 dependencies 声明”。建议提供一套可整体校验的 end-to-end fixture。
• Variance 示例中的 breathness 很可能是 breathiness 的拼写错误；duration 是否属于该 interface 也无法由本规范判定，恰好说明官方 interface-level schema 不能缺席。
• 文中称本规范定义的 variant “当前只有 onnx”，Singer 示例却使用裸词 diffsinger。如果 diffsinger 也是本规范拥有的 Singer variant，应列入；否则应使用其拥有者的命名空间。
• interface、variant 本身没有 ABNF、大小写和命名空间所有权规则；“第三方实现使用自己的 interface 命名空间”与“第三方为他人的契约提供 namespaced variant”容易被读成两种相反做法。应明确 interface 属于契约所有者，而不是实现提供者。

建议的完成条件

• 解决 optional dependency、variant 可替换性两处直接矛盾。
• 给出版本/引用 ABNF 和确定性 dependency resolver；明确 compat 不变量。
• 增加 DSPK/JSON 安全 profile、资源上限和原子安装规则。
• 发布 Package/Module 加载事务状态机与 Inference Task 状态机。
• 发布 interface-level contract registry 以及实例化前可读的 plugin descriptor。
• 给开放 category 增加命名空间、版本、requiredness 和统一 inline envelope。
• 收紧持久化 ModuleReference，并定义 import capability validation。
• 发布机器可读 schema 与跨实现 golden/negative test corpus。

这些问题多数现在修文档成本很低；等新架构、Package 和插件生态按各自理解落地后，再统一会变成格式兼容和 ABI 迁移问题。

[SineStriker]

审查范围

审查基线：docs/ds-spec-2.4.md @ 2a5a6e3。

本 issue 只讨论 spec 自身的矛盾、歧义和缺失的协议边界。refactor 是待重构的旧版本；旧代码尚未实现 2.4 不构成这里的风险，也不以旧实现作为规范真值。

2.4 把 interface、variant、开放贡献类别和统一引用拆开，方向比 2.3 清楚很多。但目前仍有若干地方会让两个“严格按文档实现”的 Installer / Loader / Executor 得到不同结果。建议在新架构冻结前至少解决下列 P0 项。

P0：建议在 2.4 冻结前解决

1. required: false 与“所有依赖都必须可加载”直接矛盾

描述文件定义了 dependencies[].required，默认 true，加载规则却规定 “当且仅当所有依赖项都能被加载”时 Package 才能加载。

最小反例：

{
  "dependencies": [
    { "id": "gpu-accel", "version": "1.0", "required": false }
  ]
}

机器未安装 gpu-accel 时，一个 Loader 可以依据 required:false 继续，另一个可以依据“所有依赖”拒绝，二者都符合原文。若模块又无条件 ref 到该依赖，跳过依赖后仍会在 Ready 阶段失败。

建议：

• 给 missing、present but incompatible、load/init failed 三种情况分别规定 required/optional 的结果；
• 明确 optional 依赖是否参与版本冲突求解；
• 为 import 增加 optional / feature gate / fallback，或明确禁止对 optional 依赖作无条件引用；
• 将“所有依赖”改为“所有 required 依赖”，并说明 optional 依赖失败是否只产生诊断。

处理方式：

• 删除dependencies[].required。每个 dependency 均为强制依赖，本规范不支持 optional dependency。
• 在《相对 2.3 的变化》中同步记录可选依赖已被删除。

2. 版本文法、依赖求解和引用绑定没有确定算法

当前字段说明只给出 x.y[.z.w]，引用 ABNF 又使用了一个未定义的 version production。因此至少这些问题没有唯一答案：

• 是否允许一段或三段版本；1.0、1.0.0、1.0.0.0 是否相等；
• 是否允许前导零，各分量上限和溢出行为是什么；
• compatVersion <= version 是否是合法清单必须满足的不变量；
• dependencies[].version 是最低兼容基线，而 ref 中的 =version 是精确安装版本、兼容基线，还是二次求解条件；
• dependency 写 bar >= 1.0、ref 写 bar=2.0:inference/x 时应报冲突、提升约束，还是加载两个实例；
• 多个搜索根或同一根中有多个兼容版本时，先按路径优先还是先取最高版本；
• diamond dependency、重复依赖、自依赖、环和同 ID 多版本是否允许并存。

“简单方案”只说依次遍历路径并取找到的兼容依赖，仍不足以让结果可复现。

建议给出完整 ABNF、规范化与比较规则，并提供一段规范性 resolver 伪代码。ref 应绑定本次依赖求解得到的实例，而不是再次做全局搜索；求解结果最好能输出包含实际版本、路径/来源和内容摘要的 resolution graph/lock。

处理方式：

• 版本号允许一至四段，比较前在右侧补0至四段。
• dependencies[].version表示依赖方要求 Package 兼容到的版本。
• compatVersion <= version是合法清单必须满足的不变量。
• 引用中的=version表示精确版本，~=version表示兼容给定版本。
• 未写版本约束的引用绑定依赖求解已经选定的 Package 实例。
• 搜索路径优先，在第一个含兼容候选的路径中选择最高版本；同一路径的同 ID 同版本候选报歧义。
• 每条依赖边独立求解，不跨边合并约束；允许多版本共存，相同 ID 与版本共享实例。
• 同一 Package 的dependencies不得重复声明相同 ID。
• 禁止 dependency 自依赖；Package 内模块使用以:开头的引用。
• 禁止依赖环，加载失败时报告环路。

3. compatVersion 没有定义“兼容”必须保持什么

当前算法只用 version >= requested && compatVersion <= requested 判断候选是否兼容，却没有定义 Package 的兼容性承诺覆盖哪些公开表面。

例如 bar@1.1 可以声称兼容 1.0，同时把 inference/pitch 的 interface 或 Level 换掉、删除某个 export，甚至复用同一模块 ID 表示另一件事。依赖方仍会被允许绑定到它，但原有 options 将按另一套契约解释。

建议明确兼容区间内至少要保持：公开 category/module ID、模块的 interface/Level 兼容关系、exports/options schema，以及可观察的运行时契约。Import 也应能声明 expected interface/level/capabilities，并在 Ready 前验证；不满足这些不变量的版本必须提升 compatVersion。

处理方式：

• 将compatVersion定义为 Package 作者作出的替换承诺，明确兼容区间内必须保持 contribution ID、契约、能力、选项与运行时语义。
• 破坏兼容承诺的版本必须提高compatVersion，使其不再覆盖受影响的旧版本。
• Loader 只按版本区间选择候选，不比较历史版本或额外验证兼容承诺；承诺不实作为 Package 缺陷诊断。

4. .dspk 的安全解包与路径封闭完全未规定

规范目前只说 .dspk 是 ZIP，声明路径相对声明文件解析，安装则只是“在某个目录中解压”。这会把安全关键行为全部留给实现猜测：

• ZIP entry 的 ..、绝对路径、盘符/UNC、反斜杠；
• symlink/junction 及“先建链接、再写链接下文件”的逃逸；
• 重复 desc.json、大小写或 Unicode 归一化后碰撞；
• 特殊文件、超长路径、zip bomb、伪造 size header、过多文件；
• 模块声明里的 ../、绝对路径，以及 ONNX external data 等二级引用逃出 Package root。

建议增加 normative DSPK profile：只允许 package-root 内的 regular files；拒绝绝对/父级/链接/特殊条目和归一化后冲突；根部恰有一份 desc.json；限制单文件/总解压字节、文件数、压缩比、路径长度、JSON 大小/深度；流式解压时再次计数；先写同文件系统 staging，完整验证后原子提交，失败整包清理。所有直接和模型格式内部的间接路径都必须在 canonicalize 后仍位于 package root。

另外应明确信任模型：若 id + version 被当作依赖身份，建议至少支持内容摘要锁定；签名由本规范承担还是由单独 distribution profile 承担，也应明确。

处理方式：

• ZIP entry 统一使用/，拒绝..、绝对路径、盘符、UNC、反斜杠和非法路径段。
• ZIP 中只允许普通文件和目录，禁止符号链接、junction、reparse point 与其他特殊文件。
• 拒绝重复 entry、文件目录重名、规范化碰撞和跨平台大小写碰撞；根部必须恰有一份desc.json。
• 使用同文件系统 staging 解压，完整验证后原子提交，失败不留下半安装 Package。
• 要求 Installer 在解压前和流式解压时执行实现定义的资源限制，并拒绝异常 ZIP。
• 路径封闭只适用于 ZIP 解包。声明中的..及模型二级引用可以越过 Package root，DSPK 加载不构成沙箱。
• 明确本规范不提供来源认证，也不要求内容摘要或签名；这些机制由分发渠道或单独的分发规范负责。

5. 推理任务只有方法名，没有可验证的生命周期与并发契约

initialize/start/startAsync/stop/state/result 没有定义：

• 合法状态与状态转移，初始化/失败/取消后能否复用；
• 同一实例是 single-flight、多并发还是有界排队，队列满时如何背压；
• startAsync 的 callback 线程、是否恰好一次、是否允许重入、对象销毁时如何处理；
• start 提交失败与任务运行失败的错误通道及优先级；
• result 何时可读、由谁持有、下一次 start 是否覆盖；
• stop 与自然完成竞态时的 terminal state，以及 deadline/timeout。

“立即停止（同步）”对不可抢占的 GPU kernel 也不是可移植的保证。建议把它改成语义明确的 cooperative cancel request，并另行定义 wait until quiescent(deadline)；给出完整状态机、每个方法的前/后置条件、幂等性、线程安全级别和资源预算/背压规则。模块加载时的 Initialized/Ready 也应与每次 inference task 的 initialize 明确分开。

6. “variant 可互换”与“exports 可以不同”互相冲突

规范先要求同一契约下各 variant “输入与输出完全一致，对导入方而言可互换”，随后又允许一个 variant 支持某项功能、另一个不支持。

最小反例：同一 (interface, level) 下 A export energy，B 不 export；Singer 的 options 要求 energy。A 替换为 B 后立即失效，因此不是无条件可互换。

建议把承诺改为“共享同一 schema/调用契约”，并把实际替换判据定义成“候选 exports 满足 importer 的 capability constraints”；Ready/Validate 阶段必须执行该检查。若真正要求无条件可替换，则同一 interface/level 的 exports 必须一致。

此外，variant 私有字段与 contract 公共字段目前共处一个 configuration 对象，未来可能键冲突；可拆成 configuration.contract / configuration.variant，或规定保留命名空间和 schema composition 规则。

处理方式：

• 删除同一契约下 variant 对导入方可互换的要求。variant 表示共享同一契约的不同实现，可以公开不同的能力集合。
• 同一 (interface, level) 的 variant 只共享exports与options的语法和运行时契约，不要求exports内容相同。
• 导入方通过 Package、类别和模块 ID 引用具体模块，并读取该模块实际声明的exports，因此知道被引用实现提供哪些能力。
• 原审查关于configuration键冲突的判断不成立。契约从不规定configuration中的公共字段，其全部语法由variant规定，因此不存在 contract 字段与 variant 字段的命名冲突。

7. interface 契约、解释器发现和 variant 演进仍不足以互操作

文档说 (interface, level) 定义 exports/options 和运行时输入输出，但没有在本规范中定义，也没有规范性链接到不可变的 interface-level contract。仅有三元组名称，无法判定两个实现对 tensor dtype/shape、单位、错误、所有权和取消语义是否真的一致。

同时，Loader 要靠三元组选择解释器，而插件章节又说三项属性在解释器实例化前就必须可读，却只描述了由解释器“返回”这些属性，没有定义静态 descriptor/factory。相同 triple 有两个 provider 时，也没有冲突或选择规则。

最后，规范明确不为 variant 设版本，允许它在 configuration 内自行版本化。但 Loader 必须在解析 variant configuration 前按 triple 选择 provider；两个不兼容配置格式仍使用同一 triple 时，选择阶段无法协商。

建议：

• 为每个官方 (interface, level) 发布不可变、可定位的 contract/schema，覆盖 exports/options/common configuration、运行时 I/O、单位、错误和任务语义；第三方 interface 同样必须有稳定的 schema identity；
• 定义实例化前可读的 registration descriptor + factory，至少含 provider/plugin ID、宿主 ABI、支持的 triple/config-format range；
• 同 triple 多 provider 默认报歧义，或只允许显式、稳定的用户策略选择，禁止依赖扫描顺序；
• 为 variant 增加标准 configFormat，或规定任何不兼容格式变化必须更换 variant ID；
• 明确 Level 历史支持方式：一个 descriptor 可广告 level 集合，或同一 provider 分别注册多个 level，避免“精确匹配”与旧模块免重发之间没有衔接。

处理方式：

• 每个 (interface, level) 必须有由 interface 所有者发布的稳定、可定位契约，至少规定exports与imports[].options的 JSON Schema 以及运行时输入输出；configuration不属于契约。
• 原审查关于“实例化前读取解释器属性”的判断不成立。三元组写在无需加载插件即可读取的插件元数据中。
• 相同三元组有多个插件时，按插件框架定义的搜索顺序选择第一个匹配项。
• configuration格式由 variant 自行版本化，版本字段放在configuration中，由解释器检查是否支持。
• 一个插件支持多个 Level 时，在插件元数据中分别列出对应的解释器条目。

P1：会破坏扩展性、确定性或跨实现一致性

8. 开放贡献类别目前仍是闭世界，而且内联表示没有统一 envelope

贡献类别被定义为开放集合，但未知类别会让 Loader 拒绝整包。一个包只要增加无关的 UI metadata 类别，旧的 headless Executor 就可能连原有 inference/singer 都无法使用。

类别名又只是裸 segment，没有命名空间、schema version 或注册冲突规则；第三方都注册 language 时无法判断语义。类别自定义的 desc entry 也没有版本轴。

此外，贡献条目可以“完全内联而不指向文件”，但后文又说所有类别模块都有由框架统一解析的 interface/level/variant 公共字段。内联条目把三元组放在哪里、是否属于“模块”，没有唯一表示。

建议采用 namespaced + versioned category descriptor，并给类别/条目 requiredness：未知 required 才失败，未知 optional 可保留并忽略。统一 contribution envelope，例如 {id, path} 与 {id, descriptor} 二选一；若允许非模块贡献，应从类型系统和术语上明确区分。

处理方式：

• 不采用 category 的required字段或额外 envelope；contributes.<category>保持为贡献条目数组，未知类别一律拒绝 Package。
• desc.json根部增加必选的runtimeVersion，在解析contributes前检查最低运行时版本要求。
• 内置类别可以使用裸名称，第三方类别必须使用反向域名；同名类别的 schema 与语义必须保持兼容，不兼容修改使用新名称。
• contribution 不一定是模块。类别注册时声明其条目是否指向模块声明；只有模块类别使用公共模块字段，非模块类别条目完全由类别定义。
• 模块类别统一使用{ id, path }指向模块声明，不提供内联模块表示；非模块贡献可以由类别自行定义内联表示。

9. 省略 category 的持久引用不是演进稳定的，PackageReference 与 ModuleReference 也未分型

引用允许省略 category 并搜索所有类别。:main 在只有 inference/main 时有效；Package 后来增加 singer/main，同一份旧 manifest 未改动却突然变成歧义。

通用 reference 还能只指向 Package，但 imports 的 options 只能由“被引用模块”的 interface/level 解释，因此 package-only ref 在 imports 中没有语义。显式写当前 Package ID 是否触发“必须在 dependencies 声明”并形成自依赖，也不清楚。

建议持久化 manifest 中的 ModuleReference 强制写 category，省略只留给交互式查询；将 PackageReference 与 ModuleReference 分型，imports 只接受后者；明确 self-reference 的例外与自依赖禁令。Imports 还应由 importer contract 定义本地 slot/alias、cardinality、重复 ref 和数组顺序语义。

处理方式：

• 将 PackageReference 与 ModuleReference 分型，并明确 ModuleReference 基于 PackageReference 追加:category/contrib-id形成。
• 声明文件中的 ModuleReference 必须包含 category，不再允许省略类别的持久化引用。
• imports[].ref只接受 ModuleReference，不接受只指向 Package 的 PackageReference，也不能指向非模块贡献。
• 当前 Package 只能使用以:开头的 ModuleReference；显式 Package ID 始终表示必须在dependencies中声明的外部 Package。
• imports是有序数组，Loader 必须保序；每个条目是独立导入实例，相同ref可以重复且不得自动去重。
• 公共格式不提供本地 slot，导入用途由被引用模块契约规定的options表达。
• 导入数量、必选项及重复是否符合具体业务要求，由导入模块的variant验证。

10. 两阶段初始化与 rollback 不是闭合的事务模型

Initialized/Ready/反序 rollback 没有说明：

• “所有模块”是当前 Package 还是整个 dependency closure；
• dependency cycle 是拒绝、SCC 两阶段，还是别的规则；
• phase 内的确定顺序是什么（contributes 是 JSON object，本身没有语义顺序）；
• 并发加载同一 Package 如何去重，何时对读者原子可见；
• A/B 共用 C 时 A 失败，C 的引用和资源是否能回滚；
• 当前失败模块的半初始化资源、rollback 自己失败、重试与 unload 如何处理。

“按相反顺序”只有在先定义唯一前向顺序并记录实际完成日志后才有意义。建议给 Package 与 Module 分别定义状态机和事务边界；先做无副作用 Resolve/Parse/Validate，再 Acquire，所有 Ready 后原子 Commit；rollback 只撤销本事务新增的引用/资源，要求幂等，并保留 primary error、附加 cleanup errors。若只支持一层跨模块引用，也应说明如何检测和诊断更深的 Ready 依赖，而不是让结果取决于遍历顺序。

11. 缺少统一 JSON、标识符和 conformance profile

规范没有明确 JSON 编码、BOM/注释、重复 key、unknown key、null 与 absent、整数范围、字符串/数组/递归上限。{"$version":"1.0","$version":"999"} 在 first-wins 与 last-wins parser 中甚至会绕过不同的版本门。

建议规范性采用 RFC 8259：UTF-8，重复 object member 一律拒绝，并明确 BOM/注释、未知字段与资源上限。标识符还需规定大小写、canonical serialization、最大长度和 collision 规则；例如 Foo/foo 在不同文件系统上不应悄悄绑定到不同对象。

同时建议：

• 定义 RFC 2119/8174 风格的 MUST/SHOULD/MAY；
• 分别列出 Installer、Loader、Executor 的 conformance 要求和验证顺序；
• 发布 desc.json、公共 module envelope 及官方 category/interface 的机器可读 schema；
• 提供正反 test corpus：版本/引用、依赖图、重复键/深度、恶意 ZIP、生命周期/取消竞态、大小写/Unicode/跨平台路径。

12. RFC 4647 Lookup 的转述不完整，路径型多语言字段也没有落到具体字段

多语言章节只描述单个偏好标签逐段右删。但 RFC 4647 Lookup 的输入通常是有序 language priority list，并且遇到 singleton extension/private-use 时要连同相邻尾段处理，不能产生 de-DE-x 这类中间候选。*、非法/废弃 tag 和 canonicalization 也未说明。

匹配又声明大小写不敏感，因此 JSON 同时出现 zh-CN 与 ZH-cn 时两键语义相同，当前没有拒绝或胜者规则。

建议直接规范性引用 RFC 4647 §3.4 的完整算法：按顺序处理 preference list，整张列表失败后才取 _；加载时校验 BCP 47 tag，并拒绝 case-fold/canonicalize 后的重复键；发布含 extension/private-use/重复大小写键的 golden vectors。

另外，“多语言字段的值是文件路径时” 目前没有对应到任何明确声明为“多语言路径”的标准字段。请逐字段说明 readme、avatar、background、demoAudio 等究竟是普通路径还是本地化路径，并让每个本地化路径都服从第 4 条的 package-root confinement。

处理方式：

• 前端每次传入一个 BCP 47 语言标签，运行时按 RFC 4647 §3.4 的单标签截断规则查找，失败后取_；不接受语言优先列表或*。
• 多语言对象中的标签按大小写不敏感方式比较，拒绝大小写折叠后重复的键。
• vendor、copyright、description与name明确为多语言文本。
• readme、avatar、background与demoAudio明确为多语言路径。
• 多语言路径分别按声明文件所在目录解析，并沿用已确定的规则，允许规范化后越过 Package root。

示例与编辑性问题

• Singer 示例引用的是 bar/pitch=1.0.0.0:inference/pitch，而 desc 示例依赖的是 bar；如果它们意在组成一份连续示例，则违反“外部 Package ID 必须在 dependencies 声明”。建议提供一套可整体校验的 end-to-end fixture。
• Variance 示例中的 breathness 很可能是 breathiness 的拼写错误；duration 是否属于该 interface 也无法由本规范判定，恰好说明官方 interface-level schema 不能缺席。
• 文中称本规范定义的 variant “当前只有 onnx”，Singer 示例却使用裸词 diffsinger。如果 diffsinger 也是本规范拥有的 Singer variant，应列入；否则应使用其拥有者的命名空间。
• interface、variant 本身没有 ABNF、大小写和命名空间所有权规则；“第三方实现使用自己的 interface 命名空间”与“第三方为他人的契约提供 namespaced variant”容易被读成两种相反做法。应明确 interface 属于契约所有者，而不是实现提供者。

建议的完成条件

• 解决 optional dependency、variant 可替换性两处直接矛盾。
• 给出版本/引用 ABNF 和确定性 dependency resolver；明确 compat 不变量。
• 增加 DSPK/JSON 安全 profile、资源上限和原子安装规则。
• 发布 Package/Module 加载事务状态机与 Inference Task 状态机。
• 发布 interface-level contract registry 以及实例化前可读的 plugin descriptor。
• 给开放 category 增加命名空间、版本、requiredness 和统一 inline envelope。
• 收紧持久化 ModuleReference，并定义 import capability validation。
• 发布机器可读 schema 与跨实现 golden/negative test corpus。

这些问题多数现在修文档成本很低；等新架构、Package 和插件生态按各自理解落地后，再统一会变成格式兼容和 ABI 迁移问题。

[yqzhishen]

第二轮复审（019f33f）

感谢这次更新。复审基线为 docs/ds-spec-2.4.md@019f33f，并已逐项核对上面的处理说明。

范围仍与首轮一致：这里只审 spec 自身；refactor 是待重构的旧版本，旧代码尚未实现 2.4 不计为风险，也不作为规范真值。

先确认处理结果：原 #1、#3、#6、#9 的主要矛盾已经闭合，#12 的 RFC 4647 singleton 截断也已正确补上；“所有依赖强制”“未知类别整包拒绝”“签名交给分发规范”等明确选择，我也不再当成歧义重复提出。原 #2、#4、#7 属于部分解决；原 #5、#10、#11 仍基本未变。下面只列新版中仍能让两个独立实现产生不同结果的部分。

P0：仍建议在 2.4 冻结前闭合

1. resolver 仍有三处未形成唯一算法

1.1 带版本的 ModuleReference 没有绑定规则

无版本引用被明确绑定到依赖求解结果，但 = / ~= 只定义了版本谓词；依赖又会先按路径优先、最高兼容版本求解。

最小反例：

A.dependencies = [{ id: bar, version: 1 }]
A 的模块 import = bar=1:inference/x
同一搜索根有 bar@1，以及 bar@2 (compatVersion=1)

dependency edge 按现规则先选 bar@2。此后至少有三种解释：

1. bar=1 只在已选的 bar@2 上作 assertion，因此失败；
2. 该引用二次搜索并额外加载 bar@1；
3. Loader 预读所有模块，把引用约束并入 dependency edge，最初就选 bar@1。

现文无法排除其中任何一种；同时写 bar=1 和 bar=2 的两个 import 时问题更明显。建议规定所有外部 ModuleReference 一律先绑定唯一的 direct-dependency edge，版本约束只作 assertion；或者规范性要求在求解前汇总所有引用约束。不要保留隐式二次全局搜索。

1.2 “兼容候选”是否包含可加载性、失败是否回退未定义

候选条件只列出 ID/version/compatVersion，但 $version、runtimeVersion 又可能整包拒绝。例如同一路径中：

bar@2: compatVersion=1, runtimeVersion=999
bar@1: compatVersion=1, runtimeVersion=1
当前 runtimeVersion=1，依赖请求 bar@1

实现可以先按版本选 bar@2 再失败，也可以先过滤不可加载项而选 bar@1。把 runtimeVersion=999 换成“传递依赖缺失”“类别/provider 不可用”也有同样问题。

请明确各阶段哪些条件属于候选 eligibility，以及选中候选后在 parse、递归 resolve、validate、initialize 的哪一阶段失败可以回退。若采用 greedy/no-backtracking，建议直接写明“最高候选一旦选中，后续失败即整条加载失败”。

这也影响 compatVersion 所谓“可以直接替换”：兼容版本允许从 onnx 改为宿主没有的 com.vendor.tensorrt，或提高 runtimeVersion，公共契约虽兼容，却不再能在原环境直接加载。应明确它仅表示 data/API compatibility，还是连宿主能力要求也属于兼容承诺。

1.3 “同 ID + 版本共享实例”与路径优先可以直接冲突

L316 要求同 ID、同规范化版本共享一个实例，但路径优先可能为不同 target 选到不同来源：

P1/bar@1: compatVersion=1, 内容 A
P2/bar@1: compatVersion=0, 内容 B
搜索顺序 P1, P2

edge X 请求 target=1 -> 选 P1/A
edge Y 请求 target=0 -> P1 不兼容，选 P2/B

两者 ID/version 相同，按 L316 必须共享；但共享 A 会使 Y 不再满足版本条件，分别实例化又违反 L316。建议 PackageInstance identity 至少包含 resolved source，或在整个 resolution graph 中先为 (id, normalized-version) 固定唯一来源并检测冲突。

2. Inference Task 仍不是可验证的接口契约

新版仍只有 initialize/start/startAsync/stop/state/result 的方法名。例如：

t.initialize()
t.startAsync(input)
t.stop()       // 与自然完成同时发生
s = t.state()
r = t.result()

实现 A 可以让自然完成胜出、结果可读；实现 B 可以让取消胜出、结果不可读，二者都不违反现文。start 是否阻塞、是否允许重复/并发 start、异步完成如何通知、错误走哪个通道、result 的所有权与有效期，也都没有答案。

“立即停止（同步）”对不可抢占的 GPU kernel 不是可移植保证。建议给出完整状态机和逐方法前/后置条件；至少定义 single-flight/背压、线程安全与原子可见性、terminal-state 竞态、错误模型、结果生命周期，并把 cooperative cancel request 与 waitUntilQuiescent(deadline) 分开。

3. 两阶段初始化与 rollback 仍不是闭合事务

相关正文仍只有 Initialized / Ready / 反序回滚。现在又规定相同 Package 实例共享，更需要回答：

• “所有模块”是当前 Package，还是本次新加载的 dependency closure；
• 前向顺序未定义时，“相反顺序”按声明、开始还是完成顺序；
• 当前正在失败的模块如何清理半初始化资源；
• A/B 共用 C，B 加载失败时如何只撤销 B 新增的引用而不破坏 A；
• 并发加载如何去重、Ready 何时原子可见；
• rollback 自身失败、重试与 unload 的语义；
• 新增的 non-module contribution 在哪一阶段解析、持有什么生命周期。

建议规范化为 Resolve -> Parse/Validate(no side effects) -> Acquire -> Ready -> Commit，定义 Package/Module 状态机、实际完成日志、失败中对象的 abort、共享实例 retain/release、幂等 cleanup，以及 primary error + cleanup errors 的诊断规则。

4. 通用模块 provider 与 configuration format 无法完成选择

公共章节要求所有模块都有三元组并据此选择解释器，imports 也可以指向任意模块类别；但唯一的 metadata/factory 协议只定义了 InferenceInterpreter。Singer 的 diffsinger variant 和第三方 module category 从哪里取得 provider，没有规范性答案。

此外，variant 可以在 configuration 内自行版本化，插件选择却只看 triple 并固定取第一个：

P1: triple=(I,1,v), 只支持 config format 1
P2: triple=(I,1,v), 只支持 config format 2
module: triple=(I,1,v), configuration.format=2
search order: P1, P2

规范强制先选 P1；直到加载 P1 后才知道不支持，P2 永远没有机会。建议定义通用 ModuleProviderDescriptor（或要求每个 module category 发布 provider-discovery 契约），并把 category、provider/plugin identity、宿主 ABI、支持的 config-format range 纳入静态 metadata。另一种闭合方式是规定任何不兼容 configuration 变化都必须更换 variant ID。

5. JSON profile 仍缺失，连最早的版本门都可能分叉

全文仍只把声明称为 JSON，没有规定 UTF-8/BOM、comments/trailing comma、重复 object member、unknown member、null/absent、Unicode 与数值范围。最小反例：

{
  "$version": "1.0",
  "id": "foo",
  "version": "1",
  "runtimeVersion": "1",
  "runtimeVersion": "999"
}

first-wins、last-wins 与 reject-duplicate parser 会在解析贡献前的版本门得到三个结果。模块里重复 interface 会进一步选择不同插件。

建议给所有声明文件定义统一 JSON profile：MUST 为 UTF-8；明确 BOM；拒绝 comments/trailing comma/NaN 和每一层的重复 member；框架 envelope 分别规定 unknown/null 策略；限制 JSON 字节、深度、节点、字符串与整数；错误包含文件和 JSON Pointer。可规范性采用 RFC 8259，再发布 desc.json、公共 module envelope 和官方 category/interface 的 schema 与 negative corpus。

P1：确定性、可移植性与扩展协议仍需补齐

6. 安全解包大幅改善，但归档和运行时路径仍不是跨平台 profile

我理解允许资源路径越过 Package root是有意选择；“不提供沙箱”解决了安全承诺的表述，却没有解决 Package 身份与可复现性：

{ "id": "x", "path": "../other/module.json" }

相同 DSPK 会随安装父目录和相邻文件变化而加载不同模块；相邻 Package 更新能改变本 Package 行为而不改变其 id/version，也绕过 dependency graph 与 staging 原子提交边界。建议至少把 contributes[].path、所有声明文件和 Package 自有资源封闭在 root；确需宿主外部文件时，用显式、经用户授权的 resource mount/host-path capability，而不是 Package 作者写裸 ..。

另外还需补一个统一的 PackagePath 文法。当前只说相对声明文件解析：modules\x.json 在 Windows 是分隔路径，在 POSIX 是字面文件名；C:secret 在 Windows 是 drive-relative 而非 absolute，也不会按声明目录解析。应统一要求 UTF-8、/ 分隔，并拒绝反斜杠、NUL、drive/UNC/device 前缀，再做词法组件解析。

ZIP profile 也仍需明确：entry 名的编码/UTF-8 flag，local 与 central header 的关键字段一致性，允许的 compression method/ZIP64/data descriptor，以及 Unicode normalization 和 Windows 保留名/ADS/尾点空格。尤其 L279 的 code span 当前是两个 U+005C（\\），按字面只禁止连续两个反斜杠；建议直接写“不得包含 U+005C REVERSE SOLIDUS（反斜杠）”。

7. runtimeVersion 没有版本权威或能力映射

runtimeVersion 是强制数字门，并被用来保护较新的内置类别，但全文没有定义“runtime”是谁的版本、谁分配、当前值是什么、何时递增，以及每个版本保证哪些 category/core capability。规范开头又面向 Installer、Loader、Executor 和第三方实现，不同产品的 1.0 没有天然可比性。

若它指 SynthRT core，请规范性写明 version authority、当前 profile 和版本到能力集合的映射；否则更适合改为 namespaced required-capabilities/category requirements。$version 已经负责文件格式门，不宜再让一个无身份的产品版本承担互操作门。

8. “稳定且可定位的契约”和类别注册仍只是要求，没有发现协议

interface contract 条款要求机器可读 schema，却没有给 interface 到 URI/registry entry 的映射；module、category registration 与 plugin metadata 也不携带 contract identity/URI/digest。两个 Loader 缓存同名 (interface,level) 的不同 schema 时，Package 无法判定谁正确，也没有离线取得和冲突处理规则。

同样，类别“注册”只规定了概念，没有 registration descriptor、schema identity、发现时点和重复名称冲突规则。两个库若把同一类别分别注册为 module/path 与 non-module/inline，会解析出不同对象类型。

建议发布规范性 contract/category registry，或定义 ContractDescriptor / CategoryDescriptor，至少含稳定 ID、schema URI+digest、entry kind、provider-discovery method 和 ABI/profile version；重复注册默认报冲突。

9. 其余低成本确定性修补

• 版本分量是无上限的 1*DIGIT。百万位整数会让 bigint、定宽整数 reject/wrap 的实现分叉；请规定每段上限/总长度及前导零、canonical serialization。
• segment 允许大小写，但 Package/category/contrib/interface/variant 的大小写和规范化未定义。建议结构标识符统一 ASCII code-point、case-sensitive，并规定最大长度；BCP 47 单独例外。
• BCP 47 的 singleton 规则已修复；剩下只需明确“有效 BCP 47”是仅 RFC 5646 well-formed，还是按某版 IANA registry valid，以及是否做 deprecated/Preferred-Value canonicalization。否则 iw/he 在 raw lookup 与 canonicalizing lookup 中结果不同。

文内仍可直接修正的例子/措辞

• desc.json 示例依赖的是 bar，Singer 示例却引用 bar/pitch=...；按新文法 Package ID 是 bar/pitch，违反 direct dependency 要求。应为 bar=1.0.0.0:inference/pitch，或把 dependency ID 改为 bar/pitch。
• 正文称当前只有裸 variant onnx，Singer 示例却使用裸 diffsinger；应补入官方 variant 列表或收窄“只有 onnx”的适用范围。
• L397 的“第三方实现使用自己的 interface 命名空间”会与下一段“第三方为他人契约提供 namespaced variant”冲突。建议改成“第三方定义的新契约使用自己的 interface 命名空间”。
• L399 所谓“同一套声明语法”与 configuration 完全由 variant 规定不一致；建议改成“共享公共 envelope、exports/options 语法及 runtime contract，configuration 可以不同”。
• breathness疑为 breathiness。

如果下一版按优先级处理，我建议先闭合：resolver 绑定与失败策略、Inference Task 状态机、Package/Module 事务、通用 provider + config-format 协商、统一 JSON profile。这五项决定两个严格实现是否能对同一 Package 得到同一个结果。

[SineStriker]

第二轮复审（019f33f）

感谢这次更新。复审基线为 docs/ds-spec-2.4.md@019f33f，并已逐项核对上面的处理说明。

范围仍与首轮一致：这里只审 spec 自身；refactor 是待重构的旧版本，旧代码尚未实现 2.4 不计为风险，也不作为规范真值。

先确认处理结果：原 #1、#3、#6、#9 的主要矛盾已经闭合，#12 的 RFC 4647 singleton 截断也已正确补上；“所有依赖强制”“未知类别整包拒绝”“签名交给分发规范”等明确选择，我也不再当成歧义重复提出。原 #2、#4、#7 属于部分解决；原 #5、#10、#11 仍基本未变。下面只列新版中仍能让两个独立实现产生不同结果的部分。

P0：仍建议在 2.4 冻结前闭合

1. resolver 仍有三处未形成唯一算法

1.1 带版本的 ModuleReference 没有绑定规则

无版本引用被明确绑定到依赖求解结果，但 = / ~= 只定义了版本谓词；依赖又会先按路径优先、最高兼容版本求解。

最小反例：

A.dependencies = [{ id: bar, version: 1 }]
A 的模块 import = bar=1:inference/x
同一搜索根有 bar@1，以及 bar@2 (compatVersion=1)

dependency edge 按现规则先选 bar@2。此后至少有三种解释：

1. bar=1 只在已选的 bar@2 上作 assertion，因此失败；
2. 该引用二次搜索并额外加载 bar@1；
3. Loader 预读所有模块，把引用约束并入 dependency edge，最初就选 bar@1。

现文无法排除其中任何一种；同时写 bar=1 和 bar=2 的两个 import 时问题更明显。建议规定所有外部 ModuleReference 一律先绑定唯一的 direct-dependency edge，版本约束只作 assertion；或者规范性要求在求解前汇总所有引用约束。不要保留隐式二次全局搜索。

处理方式：

• ModuleReference 不再携带 Package 版本。版本要求只存在于dependencies，所有外部 ModuleReference 直接绑定对应 direct dependency 已经求解出的唯一 Package 实例，不进行二次搜索。

1.2 “兼容候选”是否包含可加载性、失败是否回退未定义

候选条件只列出 ID/version/compatVersion，但 $version、runtimeVersion 又可能整包拒绝。例如同一路径中：

bar@2: compatVersion=1, runtimeVersion=999
bar@1: compatVersion=1, runtimeVersion=1
当前 runtimeVersion=1，依赖请求 bar@1

实现可以先按版本选 bar@2 再失败，也可以先过滤不可加载项而选 bar@1。把 runtimeVersion=999 换成“传递依赖缺失”“类别/provider 不可用”也有同样问题。

请明确各阶段哪些条件属于候选 eligibility，以及选中候选后在 parse、递归 resolve、validate、initialize 的哪一阶段失败可以回退。若采用 greedy/no-backtracking，建议直接写明“最高候选一旦选中，后续失败即整条加载失败”。

这也影响 compatVersion 所谓“可以直接替换”：兼容版本允许从 onnx 改为宿主没有的 com.vendor.tensorrt，或提高 runtimeVersion，公共契约虽兼容，却不再能在原环境直接加载。应明确它仅表示 data/API compatibility，还是连宿主能力要求也属于兼容承诺。

处理方式：

• 清单解析分为noLoad与load。Resolver 先以noLoad读取清单和插件元数据，不加载插件或实例化解释器；load只在成功结果上取得运行时资源。
• 候选 eligibility 明确为 Package 级静态条件，包括安全可读、有效desc.json、受支持的$version、版本兼容、runtimeLevel满足及贡献类别已注册。
• 采用 greedy/no-backtracking。候选一旦按路径优先和最高版本规则选中，后续任何 noLoad 或 load 阶段失败都直接导致加载失败，不回退其他版本或路径。
• compatVersion只承诺数据格式与 API 契约兼容，不承诺宿主满足新版本的运行时、provider 或外部资源要求。

1.3 “同 ID + 版本共享实例”与路径优先可以直接冲突

L316 要求同 ID、同规范化版本共享一个实例，但路径优先可能为不同 target 选到不同来源：

P1/bar@1: compatVersion=1, 内容 A
P2/bar@1: compatVersion=0, 内容 B
搜索顺序 P1, P2

edge X 请求 target=1 -> 选 P1/A
edge Y 请求 target=0 -> P1 不兼容，选 P2/B

两者 ID/version 相同，按 L316 必须共享；但共享 A 会使 Y 不再满足版本条件，分别实例化又违反 L316。建议 PackageInstance identity 至少包含 resolved source，或在整个 resolution graph 中先为 (id, normalized-version) 固定唯一来源并检测冲突。

处理方式：

• (id, normalized-version)唯一标识 Package，发布者必须保证同身份 Package 内容相同；内容不一致属于发布错误，Loader 不负责比较验证。
• Resolver 按搜索路径顺序为每个 Package 身份固定首次出现的唯一来源，后续路径中的同身份来源被遮蔽。
• 同一搜索路径出现多个同身份 Package 时报告歧义；不同 dependency edge 选中同一身份时共享首次来源提供的实例。
• Package root 外部资源不属于同身份内容一致承诺，但所有相对路径均按唯一选中的实际来源解析。

2. Inference Task 仍不是可验证的接口契约

新版仍只有 initialize/start/startAsync/stop/state/result 的方法名。例如：

t.initialize()
t.startAsync(input)
t.stop()       // 与自然完成同时发生
s = t.state()
r = t.result()

实现 A 可以让自然完成胜出、结果可读；实现 B 可以让取消胜出、结果不可读，二者都不违反现文。start 是否阻塞、是否允许重复/并发 start、异步完成如何通知、错误走哪个通道、result 的所有权与有效期，也都没有答案。

“立即停止（同步）”对不可抢占的 GPU kernel 不是可移植保证。建议给出完整状态机和逐方法前/后置条件；至少定义 single-flight/背压、线程安全与原子可见性、terminal-state 竞态、错误模型、结果生命周期，并把 cooperative cancel request 与 waitUntilQuiescent(deadline) 分开。

处理方式：

• Inference Task 的创建、初始化、执行、取消、状态、错误与结果生命周期全部移出本规范，由单独的运行时 API 规范定义。

3. 两阶段初始化与 rollback 仍不是闭合事务

相关正文仍只有 Initialized / Ready / 反序回滚。现在又规定相同 Package 实例共享，更需要回答：

• “所有模块”是当前 Package，还是本次新加载的 dependency closure；
• 前向顺序未定义时，“相反顺序”按声明、开始还是完成顺序；
• 当前正在失败的模块如何清理半初始化资源；
• A/B 共用 C，B 加载失败时如何只撤销 B 新增的引用而不破坏 A；
• 并发加载如何去重、Ready 何时原子可见；
• rollback 自身失败、重试与 unload 的语义；
• 新增的 non-module contribution 在哪一阶段解析、持有什么生命周期。

建议规范化为 Resolve -> Parse/Validate(no side effects) -> Acquire -> Ready -> Commit，定义 Package/Module 状态机、实际完成日志、失败中对象的 abort、共享实例 retain/release、幂等 cleanup，以及 primary error + cleanup errors 的诊断规则。

处理方式：

• 加载采用 DLL 风格强引用计数，引用来自外部 load handle、已 Commit dependency edge 和加载事务临时引用；ModuleReference 不单独计数。
• load 事务分为无副作用noLoad、Acquire、Ready 与原子 Commit，同一 Loader 上的状态变更事务串行执行。
• 已加载实例只增加临时引用，不重复初始化；Commit 时临时引用转交给根 handle 或 dependency edge。
• 失败对象清理自身半成品，已完成步骤按实际完成日志反序撤销；rollback 只释放本事务资源与引用，归零实例递归卸载。
• primary error 不被 cleanup error 覆盖，cleanup 必须幂等。
• release handle 递减引用，归零时反序卸载并递归释放 dependency 引用；non-module contribution 仅允许在noLoad中无副作用解析。

4. 通用模块 provider 与 configuration format 无法完成选择

公共章节要求所有模块都有三元组并据此选择解释器，imports 也可以指向任意模块类别；但唯一的 metadata/factory 协议只定义了 InferenceInterpreter。Singer 的 diffsinger variant 和第三方 module category 从哪里取得 provider，没有规范性答案。

此外，variant 可以在 configuration 内自行版本化，插件选择却只看 triple 并固定取第一个：

P1: triple=(I,1,v), 只支持 config format 1
P2: triple=(I,1,v), 只支持 config format 2
module: triple=(I,1,v), configuration.format=2
search order: P1, P2

规范强制先选 P1；直到加载 P1 后才知道不支持，P2 永远没有机会。建议定义通用 ModuleProviderDescriptor（或要求每个 module category 发布 provider-discovery 契约），并把 category、provider/plugin identity、宿主 ABI、支持的 config-format range 纳入静态 metadata。另一种闭合方式是规定任何不兼容 configuration 变化都必须更换 variant ID。

处理方式：

• 每个模块 category 注册专用 provider factory 与有序插件搜索路径，factory 只识别该 category 的插件；Singer provider 与 Inference interpreter 使用同一发现模型。
• 不同 category 的插件不在同一目录或候选集合中并列，因此 category 是选择 factory 的外部上下文，不加入 provider 元数据匹配键。
• provider 元数据仍以 (interface, variant, level) 三元组匹配，并按该 category 的插件搜索顺序选择第一个。
• configuration格式版本不参与静态选择。首个 provider 不支持时直接加载失败，不尝试后续 provider，符合 no-backtracking 规则。

5. JSON profile 仍缺失，连最早的版本门都可能分叉

全文仍只把声明称为 JSON，没有规定 UTF-8/BOM、comments/trailing comma、重复 object member、unknown member、null/absent、Unicode 与数值范围。最小反例：

{
  "$version": "1.0",
  "id": "foo",
  "version": "1",
  "runtimeVersion": "1",
  "runtimeVersion": "999"
}

first-wins、last-wins 与 reject-duplicate parser 会在解析贡献前的版本门得到三个结果。模块里重复 interface 会进一步选择不同插件。

建议给所有声明文件定义统一 JSON profile：MUST 为 UTF-8；明确 BOM；拒绝 comments/trailing comma/NaN 和每一层的重复 member；框架 envelope 分别规定 unknown/null 策略；限制 JSON 字节、深度、节点、字符串与整数；错误包含文件和 JSON Pointer。可规范性采用 RFC 8259，再发布 desc.json、公共 module envelope 和官方 category/interface 的 schema 与 negative corpus。

处理方式：

• 所有声明文件统一使用 UTF-8，允许并忽略 UTF-8 BOM。
• 明确允许//与/* */注释，不允许尾随逗号；除注释扩展外遵循 RFC 8259。
• 每一层 object 的重复 key 均使声明无效；null只在 schema 明确允许时合法。
• 框架 object 拒绝未知字段，类别、interface 与 variant object 按各自 schema 处理；资源限制由实现定义。

P1：确定性、可移植性与扩展协议仍需补齐

6. 安全解包大幅改善，但归档和运行时路径仍不是跨平台 profile

我理解允许资源路径越过 Package root是有意选择；“不提供沙箱”解决了安全承诺的表述，却没有解决 Package 身份与可复现性：

{ "id": "x", "path": "../other/module.json" }

相同 DSPK 会随安装父目录和相邻文件变化而加载不同模块；相邻 Package 更新能改变本 Package 行为而不改变其 id/version，也绕过 dependency graph 与 staging 原子提交边界。建议至少把 contributes[].path、所有声明文件和 Package 自有资源封闭在 root；确需宿主外部文件时，用显式、经用户授权的 resource mount/host-path capability，而不是 Package 作者写裸 ..。

另外还需补一个统一的 PackagePath 文法。当前只说相对声明文件解析：modules\x.json 在 Windows 是分隔路径，在 POSIX 是字面文件名；C:secret 在 Windows 是 drive-relative 而非 absolute，也不会按声明目录解析。应统一要求 UTF-8、/ 分隔，并拒绝反斜杠、NUL、drive/UNC/device 前缀，再做词法组件解析。

ZIP profile 也仍需明确：entry 名的编码/UTF-8 flag，local 与 central header 的关键字段一致性，允许的 compression method/ZIP64/data descriptor，以及 Unicode normalization 和 Windows 保留名/ADS/尾点空格。尤其 L279 的 code span 当前是两个 U+005C（\\），按字面只禁止连续两个反斜杠；建议直接写“不得包含 U+005C REVERSE SOLIDUS（反斜杠）”。

处理方式：

• ZIP entry 继续只接受/，并明确禁止任何 U+005C REVERSE SOLIDUS（反斜杠）。
• 声明中的运行时路径同时把/与反斜杠视为分隔符，由 Loader 在交给宿主文件系统前统一拆分和规范化。
• 声明路径仍允许.与..并可越过 Package root；绝对路径、盘符、UNC、device 前缀与 NUL 非法。
• ZIP 编码、compression method、ZIP64、data descriptor、Unicode normalization 与平台保留名称仍待决定。

7. runtimeVersion 没有版本权威或能力映射

runtimeVersion 是强制数字门，并被用来保护较新的内置类别，但全文没有定义“runtime”是谁的版本、谁分配、当前值是什么、何时递增，以及每个版本保证哪些 category/core capability。规范开头又面向 Installer、Loader、Executor 和第三方实现，不同产品的 1.0 没有天然可比性。

若它指 SynthRT core，请规范性写明 version authority、当前 profile 和版本到能力集合的映射；否则更适合改为 namespaced required-capabilities/category requirements。$version 已经负责文件格式门，不宜再让一个无身份的产品版本承担互操作门。

处理方式：

• 将runtimeVersion改为正整数runtimeLevel，由本规范维护者统一分配，不对应任何产品的软件版本。
• 当前规范定义 Runtime Level 1，并列出其保证的核心能力；新增 Package 可依赖的核心能力或内置类别时递增。
• $version负责声明格式，runtimeLevel负责核心运行时能力；provider 与第三方类别不触发 Level 递增，仍需实际安装或注册。

8. “稳定且可定位的契约”和类别注册仍只是要求，没有发现协议

interface contract 条款要求机器可读 schema，却没有给 interface 到 URI/registry entry 的映射；module、category registration 与 plugin metadata 也不携带 contract identity/URI/digest。两个 Loader 缓存同名 (interface,level) 的不同 schema 时，Package 无法判定谁正确，也没有离线取得和冲突处理规则。

同样，类别“注册”只规定了概念，没有 registration descriptor、schema identity、发现时点和重复名称冲突规则。两个库若把同一类别分别注册为 module/path 与 non-module/inline，会解析出不同对象类型。

建议发布规范性 contract/category registry，或定义 ContractDescriptor / CategoryDescriptor，至少含稳定 ID、schema URI+digest、entry kind、provider-discovery method 和 ABI/profile version；重复注册默认报冲突。

处理方式：

• interface 契约文档与 JSON Schema 面向开发者发布，Runtime 不按 interface 名称发现 registry、推导 URI、下载 Schema 或验证 digest。
• noLoad只验证公共 envelope、category 条目基础结构、注册状态、ModuleReference 绑定与 provider 元数据；契约内容由参与实现负责，variant configuration 在load时验证。
• 所有 category 在解析 Package 前完成进程内注册，注册内容包括名称、module/non-module kind 及条目解析器或 schema。
• module category 额外注册专用 provider factory 与有序插件搜索路径，non-module category 注册自己的解析器。
• 同名 category 重复注册直接报错，不按顺序覆盖或合并；Package 不能自行定义 category 语义。

9. 其余低成本确定性修补

• 版本分量是无上限的 1*DIGIT。百万位整数会让 bigint、定宽整数 reject/wrap 的实现分叉；请规定每段上限/总长度及前导零、canonical serialization。
• segment 允许大小写，但 Package/category/contrib/interface/variant 的大小写和规范化未定义。建议结构标识符统一 ASCII code-point、case-sensitive，并规定最大长度；BCP 47 单独例外。
• BCP 47 的 singleton 规则已修复；剩下只需明确“有效 BCP 47”是仅 RFC 5646 well-formed，还是按某版 IANA registry valid，以及是否做 deprecated/Preferred-Value canonicalization。否则 iw/he 在 raw lookup 与 canonicalizing lookup 中结果不同。

文内仍可直接修正的例子/措辞

• desc.json 示例依赖的是 bar，Singer 示例却引用 bar/pitch=...；按新文法 Package ID 是 bar/pitch，违反 direct dependency 要求。应为 bar=1.0.0.0:inference/pitch，或把 dependency ID 改为 bar/pitch。
• 正文称当前只有裸 variant onnx，Singer 示例却使用裸 diffsinger；应补入官方 variant 列表或收窄“只有 onnx”的适用范围。
• L397 的“第三方实现使用自己的 interface 命名空间”会与下一段“第三方为他人契约提供 namespaced variant”冲突。建议改成“第三方定义的新契约使用自己的 interface 命名空间”。
• L399 所谓“同一套声明语法”与 configuration 完全由 variant 规定不一致；建议改成“共享公共 envelope、exports/options 语法及 runtime contract，configuration 可以不同”。
• breathness疑为 breathiness。

处理方式：

• Singer 示例改为引用已声明的直接依赖bar:inference/pitch。
• 官方裸 variant 列表同时说明 Inference 的onnx与 Singer 的diffsinger。
• 明确第三方只有在定义新契约时才使用自己的 interface 命名空间。
• 将变体共享范围改为公共 envelope、exports/options语法与 runtime contract，明确configuration可以不同。
• 将breathness修正为breathiness。

如果下一版按优先级处理，我建议先闭合：resolver 绑定与失败策略、Inference Task 状态机、Package/Module 事务、通用 provider + config-format 协商、统一 JSON profile。这五项决定两个严格实现是否能对同一 Package 得到同一个结果。

[yqzhishen]

第三轮复审（f85e340）

感谢继续补齐。复审基线为 docs/ds-spec-2.4.md@f85e340，并已核对上面的逐项回复。

范围仍不变：这里只审 spec；refactor 是待重构的旧实现，尚未实现新版规范不构成风险。本轮采用更严格的严重度：

• P0 / 阻塞：正常失败路径可造成悬空调用、内存安全问题，或使核心生命周期无法安全实现。
• P1 / 重要：会让合法输入在两个实现中产生不同结果，或会迫使运行时/插件架构返工。
• P2 / 建议：低成本确定性、可移植性或示例修补，不应阻塞主要设计。

先确认进展：ModuleReference 绑定、候选 eligibility、greedy/no-backtracking、首次来源、正常加载事务、category factory、JSON 主 profile 和 runtimeLevel 权威均已基本闭合。首 provider 不支持 configuration 时直接失败也是已经写明的产品策略，不再作为歧义重复提出。Inference Task 被移出本规范后，原状态机问题也不再算本 spec 的内部缺陷。

P0：阻塞问题

1. 未能 quiesce 时仍要求释放依赖，可能把 cleanup error 变成 UAF

rollback 条款允许 cleanup 报错；release 条款又规定即使清理失败，也不恢复引用计数或重新发布实例，并继续递归释放 dependency 引用。

最小反例：

Package P 的模块 M 有 worker/callback 正在调用依赖 D
release(P)
M.cleanup() 因无法 stop/join worker 而失败
P -> D 的强引用仍按现文释放，D 归零并卸载
旧 worker 再次调用 D

这时会调用已销毁对象或已卸载插件代码。P 又已从实例表移除，随后还可能重新加载同身份 P，形成 zombie 旧实例与新实例并存。rollback 中半初始化对象无法停止时也有同样问题。

建议把清理拆成两个有明确后置条件的阶段：

1. quiesce：成功返回后，保证不再有线程、callback、in-flight 调用或导出对象访问自身、插件与依赖；
2. dispose：只在已经 quiescent 后释放资源。此阶段的某些 OS 资源释放错误可以只作附加诊断。

无法证明 quiescent 时，实例应进入不可见但仍占据 identity 的 Quarantined/CleanupFailed 状态，继续持有 dependency/plugin leases，并禁止同身份重载；可以允许重试或安全地泄漏至进程退出，但不能继续递归卸载依赖。primary error 仍可保留，不与该规则冲突。

P1：重要问题

2. Package 强引用图尚未覆盖真正执行代码的 runtime 对象

强引用来源目前只列出 root handle、dependency edge 和事务临时引用，而 task/session/callback 生命周期被移交给尚未具名的 Runtime API 规范。

跨规范最小场景是：

h = load(P)
task = module(h).createTask()
release(h)
task.start()

若 task 没有暗中 retain Package/provider，release(h)可以卸载承载其虚函数与资源的插件；若要求调用方一直保留 h，也必须由 API 明确并可验证。不同 Package 共享同一个 provider plugin 时也需要独立的 plugin lease，不能把“Package 引用计数”直接等同于“DLL 可以卸载”。

不必把 Task 状态机搬回本文件，但两份规范必须共同保证：任何能越过调用边界的 module/session/task/import binding、异步 callback 和 in-flight call，都直接或间接 pin owning Package 与 provider plugin，直到对象销毁且 callback 静默。请同时给 companion Runtime API 一个稳定名称、版本和规范性链接；provider metadata 还需声明 host API/ABI compatibility，apiLevel是 interface Level，不能代替宿主 ABI 版本。

3. “独立 import 实例”需要事务私有的 binding 语义

imports 允许相同 ref 重复，且每项是独立导入实例，但 Ready 只写成“建立运行时连接”：

"imports": [
  {"ref":"bar:inference/x", "options":{"role":"a"}},
  {"ref":"bar:inference/x", "options":{"role":"b"}}
]

目标只有一个共享 module instance。实现 A 可以创建两个独立 binding/session；实现 B 可以把同一目标全局配置两次，形成 last-wins。更严重的是，若 Ready 通过 target.registerBinding(...) 原地修改一个已 Commit target，正在运行的其他消费者会在新 Package Commit 前观察到临时状态，甚至观察到随后因失败而撤销的连接；当前“原子 Commit”只保证新实例不对其他 load 调用可见，没有覆盖普通 runtime reader。

建议定义一等 ImportBinding：每个数组项恰好产生一个由 importing module/Package 拥有的 binding handle；target provider 验证 options 并创建 binding；binding 写入完成日志，rollback/unload 时先于 importer 与 dependency edge 销毁。Ready 只能构造事务私有、尚不可见的 binding/连接图；若必须修改共享 target，则需要 prepare/commit/abort 协议或覆盖 runtime readers 的同步机制。

4. noLoad 结果需要成为不可变 LoadPlan，结构声明不能游离于 Package 身份之外

Package identity 只承诺 root 内文件相同，明确排除 root 外资源；但 contributes[].path 指向模块声明，而所有声明路径都允许越过 root。这些文件又在 noLoad 中决定 triple、provider 与 ModuleReference。

单 Loader 内即可复现：

A@1/desc.json: contributes[].path = "../shared/module.json"
第一次 load：module.json = M1，A@1 Commit
外部 module.json 改为 M2（按 L142 不属于同身份内容承诺）
随后 load C，C 依赖 A@1

实现可以复用已 Commit A@1 的缓存视图 M1，也可以在 C.noLoad 中重读 M2；若 noLoad 读到 M2、Acquire 又按实例表复用 M1，则同一事务的计划和实际对象已经不一致。类似地，来源只在“本次解析”固定，而实例表是 Loader-wide；存活实例的原来源消失后，下一事务可能为同身份计划另一来源。

建议：

• 所有被 noLoad 当作声明解析的文件必须解析到选定 Package root 内，并计入 Package identity；普通模型、词典和用户数据仍可保留现有的外部资源策略。
• noLoad 生成不可变 LoadPlan，固定 Package source、已解析声明、ModuleReference、provider metadata entry 与 plugin artifact；load(plan)不得重新求解或重扫，变化时返回 StalePlan。
• 已 Commit identity 在引用归零并完成卸载前优先于文件系统重新求解；后续 noLoad 必须绑定该现存实例及其原 source。

5. provider 的“第一个匹配项”仍缺少完整全序与 ABI eligibility

provider 发现定义了有序插件搜索路径，但没有定义同一目录内多个匹配插件的次序，也没有规定同一 metadata 内重复 triple 的处理：

plugins/a.plugin 与 plugins/b.plugin 的 triple 相同
a 支持当前 configuration，b 不支持

文件系统枚举顺序不同会让一个 Loader 成功，另一个按明确的 no-backtracking 规则失败。建议同一优先级的重复匹配直接报歧义，或定义由目录序号、稳定 plugin ID、provider entry ID 组成的完整全序；同一 manifest 内重复 triple 必须拒绝。host API/ABI compatibility 应先作为 metadata eligibility 过滤，再应用 triple/first-match，否则 ABI 不兼容的首项会遮蔽后续可用项。

6. contract schema 的验证责任和阶段仍不唯一

interface contract 要求 exports 与 options 的机器可读 Schema，但 noLoad 只把二者读为 JSON，交给“参与实现”负责。仍未明确：谁必须验证目标模块的 exports，每个 options由 target provider、importer provider 还是两者验证，以及一个从未被 import 的模块 exports 违法时 Package 能否 Commit。

无需增加 Runtime 自动下载 Schema。只需在插件加载后、取得模型/设备等重资源前增加无副作用 Validate，并规定：module provider 验证自身声明、exports与configuration；target provider 验证 target-owned options；importer provider 验证有序 binding 集合、目标 interface/level、capability 与 cardinality。所有规范性验证必须在 Commit 前结束。

7. DSPK 的 ZIP 子集仍是已知但重要的开放项

安全解包条款仍未固定 entry filename 编码、local/central header 一致性和必须支持的压缩特性；回复中也明确把它保留为待决定项。

这会导致同一归档在两个 Installer 中按 CP437/本地代码页解成不同路径，或因 compression method/ZIP64/data descriptor 支持不同而一端接受、一端拒绝。畸形归档还可以让 central directory 是安全名称、local header 是另一名称，使“验证的名字”和“实际写入的名字”取决于 ZIP 库。

建议 DSPK 固定 UTF-8 filename profile，规定 Unicode extra field 冲突处理；至少要求 store/deflate 的一致支持并明确 ZIP64/data descriptor；local 与 central header 的 filename、flags、method、size 等关键字段必须一致，否则拒绝。此项定为 P1，不与上面的生命周期 P0 同级。

P2：低成本修补与 producer profile

8. runtimeLevel 可选但没有缺省值

runtimeLevel 被列为可选字段，当前只定义 Level 1。现阶段把缺省解释为“无额外要求”或 Level 1 的加载结果相同，所以不应升为阻塞；建议补一句“缺省为 1”，或直接设为必选。

9. JSON 注释扩展需要固定词法

JSON profile允许 //与/* */，但未说明 block comment 是否可嵌套、//由哪些 Unicode line terminator 结束、注释允许出现的位置。建议直接引用一个固定 JSONC grammar，或明确采用 C 风格、不允许嵌套，并列出行终止符。

10. 标识符、版本与本地化仍有几项确定性细节

• Package/category/contribution ID 及 interface/variant 的大小写与规范化尚未统一说明。建议结构标识符按 ASCII/code-point、case-sensitive 精确比较；BCP 47 单独保持 case-insensitive。
• version 分量仍是无上限 1*DIGIT。建议给每段和总长度上限，并规定前导零的 canonical serialization。
• BCP 47 的 singleton 截断已解决；剩余只需明确“有效标签”是 RFC 5646 well-formed 还是按某版 IANA registry valid，以及是否执行 deprecated/Preferred-Value canonicalization。

11. 跨平台文件名与示例路径

• 即使 ZIP 使用 UTF-8，NFC/NFD、Win32 CON/ADS、尾点与尾空格仍会影响跨平台可安装性。可给 producer 一个 portable filename profile；这属于可移植性建议，不再作为安全解包 P0。
• Singer 示例从 singer.json 使用 ../assets/...，而推荐结构把它放在 singers/singer1/singer.json；按当前基路径规则会解析到 singers/assets，不是根部 assets。示例应使用 ../../assets/...，或调整推荐目录。

建议处理顺序

1. 先修 P0 的 quiesce / quarantine 语义。
2. 再冻结 Package/provider/task/binding 的跨规范 lease 与 Ready 原子性。
3. 固定 LoadPlan、provider 全序和 ZIP profile。
4. P2 可作为一次集中编辑，不应阻塞前述架构决策。

除上述异常清理路径外，f85e340 的正常 resolver 与加载事务已经形成可实现的确定模型；第三轮不建议再推翻其 greedy、首次来源或 first-provider 等已明确策略。

[SineStriker]

第三轮复审（f85e340）

感谢继续补齐。复审基线为 docs/ds-spec-2.4.md@f85e340，并已核对上面的逐项回复。

范围仍不变：这里只审 spec；refactor 是待重构的旧实现，尚未实现新版规范不构成风险。本轮采用更严格的严重度：

• P0 / 阻塞：正常失败路径可造成悬空调用、内存安全问题，或使核心生命周期无法安全实现。
• P1 / 重要：会让合法输入在两个实现中产生不同结果，或会迫使运行时/插件架构返工。
• P2 / 建议：低成本确定性、可移植性或示例修补，不应阻塞主要设计。

先确认进展：ModuleReference 绑定、候选 eligibility、greedy/no-backtracking、首次来源、正常加载事务、category factory、JSON 主 profile 和 runtimeLevel 权威均已基本闭合。首 provider 不支持 configuration 时直接失败也是已经写明的产品策略，不再作为歧义重复提出。Inference Task 被移出本规范后，原状态机问题也不再算本 spec 的内部缺陷。

P0：阻塞问题

1. 未能 quiesce 时仍要求释放依赖，可能把 cleanup error 变成 UAF

rollback 条款允许 cleanup 报错；release 条款又规定即使清理失败，也不恢复引用计数或重新发布实例，并继续递归释放 dependency 引用。

最小反例：

Package P 的模块 M 有 worker/callback 正在调用依赖 D
release(P)
M.cleanup() 因无法 stop/join worker 而失败
P -> D 的强引用仍按现文释放，D 归零并卸载
旧 worker 再次调用 D

这时会调用已销毁对象或已卸载插件代码。P 又已从实例表移除，随后还可能重新加载同身份 P，形成 zombie 旧实例与新实例并存。rollback 中半初始化对象无法停止时也有同样问题。

建议把清理拆成两个有明确后置条件的阶段：

1. quiesce：成功返回后，保证不再有线程、callback、in-flight 调用或导出对象访问自身、插件与依赖；
2. dispose：只在已经 quiescent 后释放资源。此阶段的某些 OS 资源释放错误可以只作附加诊断。

无法证明 quiescent 时，实例应进入不可见但仍占据 identity 的 Quarantined/CleanupFailed 状态，继续持有 dependency/plugin leases，并禁止同身份重载；可以允许重试或安全地泄漏至进程退出，但不能继续递归卸载依赖。primary error 仍可保留，不与该规则冲突。

• **处理方式：**采用类似进程退出的 quit / wait 两个停止原语。quit只请求停止，wait成功是实例不再执行代码或访问自身、provider plugin 与 dependency 的安全屏障；只有成功 wait 后才销毁资源并释放相关引用。wait 失败或超时时，实例进入不可见但仍占据 Package 身份的Quarantined状态，保留资源及 dependency/plugin 引用，禁止同身份重载，可重试停止或保留至进程退出。该规则同时适用于正常卸载和 rollback 中的未 Commit 实例。

P1：重要问题

2. Package 强引用图尚未覆盖真正执行代码的 runtime 对象

强引用来源目前只列出 root handle、dependency edge 和事务临时引用，而 task/session/callback 生命周期被移交给尚未具名的 Runtime API 规范。

跨规范最小场景是：

h = load(P)
task = module(h).createTask()
release(h)
task.start()

若 task 没有暗中 retain Package/provider，release(h)可以卸载承载其虚函数与资源的插件；若要求调用方一直保留 h，也必须由 API 明确并可验证。不同 Package 共享同一个 provider plugin 时也需要独立的 plugin lease，不能把“Package 引用计数”直接等同于“DLL 可以卸载”。

不必把 Task 状态机搬回本文件，但两份规范必须共同保证：任何能越过调用边界的 module/session/task/import binding、异步 callback 和 in-flight call，都直接或间接 pin owning Package 与 provider plugin，直到对象销毁且 callback 静默。请同时给 companion Runtime API 一个稳定名称、版本和规范性链接；provider metadata 还需声明 host API/ABI compatibility，apiLevel是 interface Level，不能代替宿主 ABI 版本。

• **处理方式：**本规范不规定 task、session 等运行时对象各自的引用计数或要求 Package 调用方额外保留 handle，而将其统一规定为 Runtime API 的责任：wait成功后，该 Package 产生的全部执行活动必须停止，运行时资源必须释放或安全脱离，遗留 handle 必须失效且不得再进入 Package、dependency 或 provider plugin 代码。由此保证 wait 成功后可以安全释放 Package 与 plugin；无法保证时适用 P0 的Quarantined规则。Runtime API 的具体文档名称与版本不属于本 Package 格式规范；provider 的宿主 API/ABI eligibility 作为本轮第 5 项单独处理。

3. “独立 import 实例”需要事务私有的 binding 语义

imports 允许相同 ref 重复，且每项是独立导入实例，但 Ready 只写成“建立运行时连接”：

"imports": [
  {"ref":"bar:inference/x", "options":{"role":"a"}},
  {"ref":"bar:inference/x", "options":{"role":"b"}}
]

目标只有一个共享 module instance。实现 A 可以创建两个独立 binding/session；实现 B 可以把同一目标全局配置两次，形成 last-wins。更严重的是，若 Ready 通过 target.registerBinding(...) 原地修改一个已 Commit target，正在运行的其他消费者会在新 Package Commit 前观察到临时状态，甚至观察到随后因失败而撤销的连接；当前“原子 Commit”只保证新实例不对其他 load 调用可见，没有覆盖普通 runtime reader。

建议定义一等 ImportBinding：每个数组项恰好产生一个由 importing module/Package 拥有的 binding handle；target provider 验证 options 并创建 binding；binding 写入完成日志，rollback/unload 时先于 importer 与 dependency edge 销毁。Ready 只能构造事务私有、尚不可见的 binding/连接图；若必须修改共享 target，则需要 prepare/commit/abort 协议或覆盖 runtime readers 的同步机制。

• **处理方式：**每个imports数组项恰好创建一个由 importing module 拥有的独立 ImportBinding；目标 module instance 可以共享，但各项的ref、options与连接状态不得合并、互相覆盖或写成目标的全局配置。Ready 只能构造事务私有且不可见的 binding，Commit 才将其随 Package 原子发布。binding 进入事务完成日志，rollback 与卸载时先于 importing module 和 dependency edge 销毁。确实需要修改已 Commit 共享目标的 provider 必须提供 prepare / commit / abort 等价机制或完整同步，保证 Commit 前不可见且 rollback 无残留。

4. noLoad 结果需要成为不可变 LoadPlan，结构声明不能游离于 Package 身份之外

Package identity 只承诺 root 内文件相同，明确排除 root 外资源；但 contributes[].path 指向模块声明，而所有声明路径都允许越过 root。这些文件又在 noLoad 中决定 triple、provider 与 ModuleReference。

单 Loader 内即可复现：

A@1/desc.json: contributes[].path = "../shared/module.json"
第一次 load：module.json = M1，A@1 Commit
外部 module.json 改为 M2（按 L142 不属于同身份内容承诺）
随后 load C，C 依赖 A@1

实现可以复用已 Commit A@1 的缓存视图 M1，也可以在 C.noLoad 中重读 M2；若 noLoad 读到 M2、Acquire 又按实例表复用 M1，则同一事务的计划和实际对象已经不一致。类似地，来源只在“本次解析”固定，而实例表是 Loader-wide；存活实例的原来源消失后，下一事务可能为同身份计划另一来源。

建议：

• 所有被 noLoad 当作声明解析的文件必须解析到选定 Package root 内，并计入 Package identity；普通模型、词典和用户数据仍可保留现有的外部资源策略。

• noLoad 生成不可变 LoadPlan，固定 Package source、已解析声明、ModuleReference、provider metadata entry 与 plugin artifact；load(plan)不得重新求解或重扫，变化时返回 StalePlan。

• 已 Commit identity 在引用归零并完成卸载前优先于文件系统重新求解；后续 noLoad 必须绑定该现存实例及其原 source。

• **处理方式：**不引入不可变 LoadPlan、StalePlan或 root 内声明限制。Package 发布者必须保证同一身份的全部 Package 文件、root 外直接或间接引用及其相对布局一致，并在解析、加载和使用期间保持稳定；违反要求属于 Package 缺陷，运行时行为未定义。Runtime 可以缓存noLoad结果，也可以在load中重新读取或解析，不负责比较来源、监视文件变化或诊断不一致。存活实例继续按既有实例表和首次来源规则复用。

5. provider 的“第一个匹配项”仍缺少完整全序与 ABI eligibility

provider 发现定义了有序插件搜索路径，但没有定义同一目录内多个匹配插件的次序，也没有规定同一 metadata 内重复 triple 的处理：

plugins/a.plugin 与 plugins/b.plugin 的 triple 相同
a 支持当前 configuration，b 不支持

文件系统枚举顺序不同会让一个 Loader 成功，另一个按明确的 no-backtracking 规则失败。建议同一优先级的重复匹配直接报歧义，或定义由目录序号、稳定 plugin ID、provider entry ID 组成的完整全序；同一 manifest 内重复 triple 必须拒绝。host API/ABI compatibility 应先作为 metadata eligibility 过滤，再应用 triple/first-match，否则 ABI 不兼容的首项会遮蔽后续可用项。

• **处理方式：**保留 first-match 策略，并将扫描全序定义为用户给定的插件搜索目录顺序，以及每个目录中按 basename Unicode 码点升序、区分大小写排列的文件名顺序，不采用文件系统枚举顺序或 locale。同一插件的 provider 元数据数组不得重复声明相同三元组，重复时整个插件元数据无效。不引入 host API/ABI eligibility；插件二进制兼容性由部署者保证，选中插件加载失败或二进制不兼容属于严重加载错误，整次加载失败且不得回退到后续 provider。

6. contract schema 的验证责任和阶段仍不唯一

interface contract 要求 exports 与 options 的机器可读 Schema，但 noLoad 只把二者读为 JSON，交给“参与实现”负责。仍未明确：谁必须验证目标模块的 exports，每个 options由 target provider、importer provider 还是两者验证，以及一个从未被 import 的模块 exports 违法时 Package 能否 Commit。

无需增加 Runtime 自动下载 Schema。只需在插件加载后、取得模型/设备等重资源前增加无副作用 Validate，并规定：module provider 验证自身声明、exports与configuration；target provider 验证 target-owned options；importer provider 验证有序 binding 集合、目标 interface/level、capability 与 cardinality。所有规范性验证必须在 Commit 前结束。

• 处理方式：noLoad只将exports、options与configuration作为 JSON 读取，不验证具体契约，也不发现或下载 Schema。现有load流程负责验证且不增加独立 Validate 阶段：每个模块的 provider 在 Acquire 验证自身声明、exports与configuration；target provider 在 Ready 验证对应options；importing provider 验证有序 imports 集合的数量、顺序、目标契约、能力和组合关系。Package 中未被 import 的模块也必须验证。任何错误都使整次加载失败并 rollback，Package 不得 Commit，也不得回退到其他 provider。

7. DSPK 的 ZIP 子集仍是已知但重要的开放项

安全解包条款仍未固定 entry filename 编码、local/central header 一致性和必须支持的压缩特性；回复中也明确把它保留为待决定项。

这会导致同一归档在两个 Installer 中按 CP437/本地代码页解成不同路径，或因 compression method/ZIP64/data descriptor 支持不同而一端接受、一端拒绝。畸形归档还可以让 central directory 是安全名称、local header 是另一名称，使“验证的名字”和“实际写入的名字”取决于 ZIP 库。

建议 DSPK 固定 UTF-8 filename profile，规定 Unicode extra field 冲突处理；至少要求 store/deflate 的一致支持并明确 ZIP64/data descriptor；local 与 central header 的 filename、flags、method、size 等关键字段必须一致，否则拒绝。此项定为 P1，不与上面的生命周期 P0 同级。

• **处理方式：**只固定 ZIP entry 文件名必须使用 UTF-8，不得按 CP437、系统代码页或 locale 解码，并继续要求所有成功安装结果满足现有路径封闭、普通文件与目录限制、资源限制、CRC 检查和原子安装规则。不制定 DSPK 专用 ZIP 子集；compression method、ZIP64、data descriptor、Unicode extra field 与 header 解析细节交给 ZIP 实现，不支持时可以拒绝，且不要求不同安装器接受相同特性集合。ZIP 实现判定归档损坏或元数据矛盾时整包拒绝。

P2：低成本修补与 producer profile

8. runtimeLevel 可选但没有缺省值

runtimeLevel 被列为可选字段，当前只定义 Level 1。现阶段把缺省解释为“无额外要求”或 Level 1 的加载结果相同，所以不应升为阻塞；建议补一句“缺省为 1”，或直接设为必选。

• 处理方式：runtimeLevel改为desc.json的必选正整数字段，不设缺省值。当前规范只分配 Level 1，因此当前 conforming Package 必须写"runtimeLevel": 1；字段缺失、类型或取值非法，或高于运行时支持的最高 Level 时整包拒绝。相对 2.3 的变化表同步明确该字段必选。

9. JSON 注释扩展需要固定词法

JSON profile允许 //与/* */，但未说明 block comment 是否可嵌套、//由哪些 Unicode line terminator 结束、注释允许出现的位置。建议直接引用一个固定 JSONC grammar，或明确采用 C 风格、不允许嵌套，并列出行终止符。

• **处理方式：**有意不固定 JSONC grammar。规范继续允许字符串之外的//与/* */注释，字符串内的相同文本不作为注释；嵌套、行终止符及其他词法边界由实现所用 JSON 解析器定义，依赖这些边界差异的声明不保证跨实现兼容。当前实现可直接使用 stdcorelib 的注释忽略能力。

10. 标识符、版本与本地化仍有几项确定性细节

• Package/category/contribution ID 及 interface/variant 的大小写与规范化尚未统一说明。建议结构标识符按 ASCII/code-point、case-sensitive 精确比较；BCP 47 单独保持 case-insensitive。

• version 分量仍是无上限 1*DIGIT。建议给每段和总长度上限，并规定前导零的 canonical serialization。

• BCP 47 的 singleton 截断已解决；剩余只需明确“有效标签”是 RFC 5646 well-formed 还是按某版 IANA registry valid，以及是否执行 deprecated/Preferred-Value canonicalization。

• **处理方式：**Package/category/contribution ID 与interface、variant统一限制为文法规定的 ASCII 字符，区分大小写并逐字节精确比较，不做 Unicode normalization、locale 转换或大小写折叠；BCP 47 保持大小写无关。版本数字分量参考 Semantic Versioning：除0外禁止前导零，不设固定数值上限，按任意精度整数比较，右侧补零后的四段形式是规范化序列化。BCP 47 当前只要求按 RFC 5646 语法良构，不查 IANA registry，不替换 deprecated subtag 或 Preferred-Value。

11. 跨平台文件名与示例路径

• 即使 ZIP 使用 UTF-8，NFC/NFD、Win32 CON/ADS、尾点与尾空格仍会影响跨平台可安装性。可给 producer 一个 portable filename profile；这属于可移植性建议，不再作为安全解包 P0。
• Singer 示例从 singer.json 使用 ../assets/...，而推荐结构把它放在 singers/singer1/singer.json；按当前基路径规则会解析到 singers/assets，不是根部 assets。示例应使用 ../../assets/...，或调整推荐目录。

建议处理顺序

1. 先修 P0 的 quiesce / quarantine 语义。
2. 再冻结 Package/provider/task/binding 的跨规范 lease 与 Ready 原子性。
3. 固定 LoadPlan、provider 全序和 ZIP profile。
4. P2 可作为一次集中编辑，不应阻塞前述架构决策。

除上述异常清理路径外，f85e340 的正常 resolver 与加载事务已经形成可实现的确定模型；第三轮不建议再推翻其 greedy、首次来源或 first-provider 等已明确策略。

[yqzhishen]

第四轮复审（796e74f）

感谢继续完善。复审基线为 docs/ds-spec-2.4.md@796e74f，并已核对第三轮处理说明。

范围仍不变：这里只审 spec；refactor 是待重构的旧实现，尚未实现新版规范不构成风险。本轮继续严格分级：P0 只保留合法生命周期路径中会确定性死锁、悬空访问或破坏隔离屏障的问题；P1 是可能导致实现分叉或运行时架构返工的问题；P2 是低成本的确定性、可移植性和示例修补。

先确认本次进展：第三轮的 quiesce / cleanup UAF 已通过 quit、wait、Quarantined和引用保留机制在正常卸载路径上闭合；独立 ImportBinding 的创建与 Commit 可见性、契约验证职责、provider 扫描全序、runtimeLevel、结构标识符、版本和 BCP 47 也都已补齐。Package/外部资源稳定性、JSONC 边界、ZIP feature 集和 ABI fallback 已被明确设为产品取舍，本轮不再把它们当成未说明的歧义。

P0：阻塞问题

1. 最后一个 handle 在自身 in-flight 调用中释放，会形成 self-wait

release 会在引用归零后依次执行 quit / wait，而 wait又必须等待该实例的全部 callback 和 in-flight 调用结束。规范没有禁止在 callback 中释放最后一个根 handle，也没有给这种情况定义延迟回收语义：

Package P 的 callback C 正在执行
C 调用 release(lastRootHandle(P))
release -> refcount 归零 -> P.quit() -> P.wait()
P.wait() 等待 C 返回
C 等待 release 返回

同步执行会确定性自等待；若为了避开死锁而直接卸载，callback 返回时又会跳回已经卸载的 plugin 代码。超时后隔离虽然避免了 UAF，却会让一个原本正常的调用序列必然产生永久 tombstone。

同一问题也会出现在 Loader 的串行事务锁上：provider 的 callback/退出线程若重入同一 Loader 的 load或release，外层 wait等待该线程，而内层操作等待外层事务结束。

建议明确：

• 每个进入 Package/plugin 的调用持有 transient activity lease；最后一个外部 handle 在 activity 内释放时只原子转为 Stopping，实际 quit/wait 延迟到该 activity 退出后执行；
• 或明确这种 last-release 只能排队异步 teardown，绝不能在被等待的执行上下文中同步 wait；
• Loader 调用 provider/user code或阻塞 wait 时，不得持有退出路径所需的全局事务锁；若选择禁止重入，则必须由 Runtime API 明确规定并检测；
• 延迟 teardown 期间继续保留 identity reservation，不能提前允许同身份重载。

2. rollback 会停止完成日志中的全部实例，却又要求 Quarantined dependent 保留并继续依赖它们

rollback 规则要求当前失败对象和完成日志中的运行时实例执行 quit / wait；隔离规则又要求 wait 失败的实例保留 dependency 引用，且明确不能继续递归卸载其依赖。两条在同一事务中会冲突：

本事务新建 P -> D
P.wait() 超时；P 仍可能执行并访问 D，故 P 进入 Quarantined 并保留 P -> D
D 也在本事务完成日志中
rollback 继续按 L409 对 D 执行 quit / wait

如果 D 成功 wait，它已经停止并释放或脱离运行时资源，但 P 的未静默活动仍可能调用 D。保留引用只能防止对象/插件被卸载，不能把已经 quit 的 D 恢复为可用状态；若随后再按日志清理 D 的 Acquire 产物，风险会进一步升级为悬空访问。这也直接违背“不能继续递归卸载其依赖”的后置条件。

建议 rollback 按 dependency 逆拓扑和当前引用状态推进：一旦某个 dependent 无法 quiesce，它仍可能访问的 ImportBinding、dependency 和 provider plugin 都不得再 quit/destroy。未 Commit 的所需闭包应进入不可发布但占据 identity 的 RetainedByQuarantine状态；只有 dependent 后续 wait 成功并销毁、相应边被释放且 dependency 真正归零后，才能开始停止该 dependency。L409 的“完成日志中的运行时实例”应明确排除仍被未静默 dependent 保留的实例。

P1：重要问题

3. Stopping / Quarantined没有宿主侧 ingress gate，旧 handle 可能继续提交新工作

quit只是“请求”停止接收新工作；wait 失败后的条款只说实例对 Loader 不可见并保留资源。只有 wait 成功时，正文才保证遗留 runtime handle 已失效。

因此 quit报错、wait超时、P 进入 Quarantined 后，调用方继续用旧 task/session handle 调 start()时，一种实现会进入隐藏实例，另一种会拒绝。前者还能不断产生新活动，使后续重试 wait 永远无法成功。

建议在 Running -> Stopping转换时，先由 Runtime-owned gate 原子拒绝所有新的外部调用，再进入 provider quit；Quarantined 永久保持 gate closed，只允许既有 in-flight 活动退出及管理面的 retry quit/wait。该 gate 必须位于不会随 provider 卸载的宿主代理中。

4. ImportBinding 有创建事务，但没有对称的 close / drain 卸载协议

Ready / Commit已很好地规定了 binding 的创建与原子发布；卸载规则只规定 wait 成功后销毁 binding、importer，最后释放 dependency edge。

设 P 通过 B import 一个仍被其他 Package 使用的已 Commit 目标 D，D 的线程可通过 B 向 P 投递 callback：

• 先 wait(P)、后销毁 B：若没有先撤销 D 侧入口，D 可以继续产生新 callback，P 无法 quiesce；
• wait 前直接 free B：D 已取得但尚未完成的 callback 可能访问已释放的 B。

建议规定对称生命周期：B.close/unpublish先原子拒绝双方的新调用和 callback，但保持对象存活；B.drain/wait等待双向 in-flight 归零；Package wait 覆盖其全部 binding drain；成功后才 destroy B、destroy importer，最后释放 dependency/plugin lease。共享 target 侧需要使用与创建时对称的锁、epoch、RCU/grace period 或等价机制。

5. provider 选择结果没有绑定到已 Commit 实例和实际插件工件

noLoad选择 provider metadata，Acquire 才加载插件，且已 Commit 实例不重复 Acquire。Package 的稳定性承诺不覆盖 provider 搜索目录、metadata 或二进制。

有两个可复现分叉：

1. P@1 已经用 b.plugin Commit；插件目录随后新增排序更早的 a.plugin。新 C 依赖 P@1 时，一实现复用 P 实例记录的 b，另一实现按 noLoad 重新选择 a，但 Acquire 又实际复用旧 P/b。
2. 新实例 noLoad 读取 a.plugin metadata 后、Acquire 打开二进制前，a.plugin被替换。一实现使用已打开的工件，另一实现按路径加载替换后的代码。

建议已 Commit/Quarantined identity 的 provider 绑定成为实例状态，后续 noLoad 必须复用而不得重新发现；仅对本事务新实例执行发现，并把选中的 metadata entry 绑定到精确 artifact（打开句柄或等价 file identity），冻结到 Acquire。变化只能报告 stale/serious loading error，不得悄悄重扫或改选。这里不要求恢复持久化 Package LoadPlan。

6. provider plugin 强引用缺少取得、转交和共享规则

正文只在成功 wait 后释放、Quarantined 时保留处提到 provider plugin 强引用；Acquire 只写“加载插件”，没有定义 lease 何时取得、由 Package/module/backend 中谁持有，以及多个模块、Package 或 Loader 共用同一动态库时如何合并。

P.module -> x.plugin
Q.module -> x.plugin
load(P); load(Q); release(P); Q.module.call()

需要一个明确的安全不变量：在调用任何 factory/entrypoint 前取得临时 plugin lease并写入事务日志；Commit 后所有 plugin 派生对象和 backend 都由某个仍存活的 lease 覆盖；rollback 只释放本事务 lease；Quarantined 保留完整 lease 集；全部 module、ImportBinding backend 和析构函数执行完成后，最后一个 lease 才能释放。实现可自行选择进程级实例表或 OS library refcount，但不能让一个 Package 的卸载使另一个 Package 的代码指针失效。

7. provider 事务钩子的失败与副作用边界不足以保证原子 Commit

L403允许共享目标使用 prepare / commit / abort，但未规定 provider 的 commit hook 是否可失败：

Ready: prepare(T1), prepare(T2) 均成功
Commit: T1.commit() 已对运行时可见
Commit: T2.commit() 抛错

此时无法满足整个闭包的原子发布，也未必能用 abort 撤销已经公开的 T1。类似地，validateOptions()若预分配 session 或写缓存，随后 importer 集合验证失败，而该副作用没有形成日志步骤，rollback 也无从撤销。

建议规定所有 validation callback 只读且不得留下持久副作用；确需预留资源时必须返回立即写入日志、可 abort 的事务私有 PreparedToken。Ready/prepare 完成全部可能失败、分配或 I/O 的工作；Commit hook 必须 non-failing/noexcept，只做已准备状态的指针或 epoch publication，并与实例表发布处于同一可见性屏障。

8. Quarantined identity 在依赖候选中是“过滤”还是“选中后失败”未定义

候选与 greedy/no-backtracking 算法没有把实例状态列为 eligibility 条件；L428又要求拒绝重新加载相同 identity。

bar@2 (compatVersion=1) 已 Quarantined
bar@1 (compatVersion=1) 正常可用
新 Package 请求 dependency bar@1

实现可以先过滤不可重载的 bar@2 而选择 bar@1，也可以仍按最高版本选中 bar@2、随后以 IdentityQuarantined失败且不得回退。建议明确 tombstone 与候选 eligibility 的关系。若保持严格 greedy，最直接的规则是照常选中 bar@2 后失败且不回退；若希望自动降级，则应明确在排序前过滤。

P2：建议与文字修补

9. plugin discovery 的坏元数据和文件名边界仍缺统一处理

L514-L518规定重复 triple 使整个 plugin metadata 无效，却没说明应跳过该插件还是终止本次发现。例如 a.plugin metadata 重复、b.plugin合法匹配时，两种处理会得到失败与成功。建议同时列清无法读取、JSON 无效、重复 triple、扫描中消失、非插件文件的统一政策。

此外，basename 按 Unicode 码点排序时，应说明 POSIX 非 UTF-8 文件名是跳过还是报错，并明确 basename 是否指包含扩展名的最终路径段。

10. wait与 dispose 对运行时资源的所有权措辞重叠

L424说 wait 成功时运行时资源已经“释放或与实例安全脱离”，L426又说此后 Loader 才销毁模块和运行时资源。建议把后置条件拆清：wait 只保证 quiescent、无未来自主/外部访问；dispose 销毁仍归实例所有的资源。Loader-exclusive teardown 是 wait 后唯一允许继续进入 provider/dependency 的同步路径，且不得再启动异步活动。

11. ZIP 的“header 大小”应指解析 feature 后的有效值

L331-L333一面要求实际大小与 header 不符时拒绝，一面允许实现支持 data descriptor 和 ZIP64。前者若按 raw local header 字面执行，会误拒绝合法的 data-descriptor 零占位或 ZIP64 的 0xffffffff sentinel。建议改成：实际流式结果必须与“按该实现支持的 ZIP feature 解析出的 authoritative/effective CRC 与 size”一致，并按相应 feature 验证 local header、central directory、extra field 与 descriptor 的关系。

若支持 Unicode Path extra field，也可顺手明确它与 EFS/raw UTF-8 文件名谁是 authoritative；二者冲突时必须拒绝，不能让验证路径与实际写入路径来自不同字段。

12. Singer 示例路径与推荐目录仍相差一级

Singer 示例使用 ../assets/...；按推荐目录，singer.json位于 singers/singer1/，根部 assets 应写成 ../../assets/...。avatar、background、demoAudio和示例中的 configuration.dictionary都需要同步修改，或者调整推荐目录结构。

总体上，这一版已经从“解析与求解规则不闭合”推进到了“销毁与隔离边界需要最后闭环”的阶段。建议优先处理两个 P0，以及 P1 #3–#5；它们共同决定合法回调路径能否完成卸载、隔离实例是否真正停止接收工作，以及 noLoad 选中的 provider 是否就是最终执行的那份代码。

[SineStriker]

第四轮复审（796e74f）

感谢继续完善。复审基线为 docs/ds-spec-2.4.md@796e74f，并已核对第三轮处理说明。

范围仍不变：这里只审 spec；refactor 是待重构的旧实现，尚未实现新版规范不构成风险。本轮继续严格分级：P0 只保留合法生命周期路径中会确定性死锁、悬空访问或破坏隔离屏障的问题；P1 是可能导致实现分叉或运行时架构返工的问题；P2 是低成本的确定性、可移植性和示例修补。

先确认本次进展：第三轮的 quiesce / cleanup UAF 已通过 quit、wait、Quarantined和引用保留机制在正常卸载路径上闭合；独立 ImportBinding 的创建与 Commit 可见性、契约验证职责、provider 扫描全序、runtimeLevel、结构标识符、版本和 BCP 47 也都已补齐。Package/外部资源稳定性、JSONC 边界、ZIP feature 集和 ABI fallback 已被明确设为产品取舍，本轮不再把它们当成未说明的歧义。

P0：阻塞问题

1. 最后一个 handle 在自身 in-flight 调用中释放，会形成 self-wait

release 会在引用归零后依次执行 quit / wait，而 wait又必须等待该实例的全部 callback 和 in-flight 调用结束。规范没有禁止在 callback 中释放最后一个根 handle，也没有给这种情况定义延迟回收语义：

Package P 的 callback C 正在执行
C 调用 release(lastRootHandle(P))
release -> refcount 归零 -> P.quit() -> P.wait()
P.wait() 等待 C 返回
C 等待 release 返回

同步执行会确定性自等待；若为了避开死锁而直接卸载，callback 返回时又会跳回已经卸载的 plugin 代码。超时后隔离虽然避免了 UAF，却会让一个原本正常的调用序列必然产生永久 tombstone。

同一问题也会出现在 Loader 的串行事务锁上：provider 的 callback/退出线程若重入同一 Loader 的 load或release，外层 wait等待该线程，而内层操作等待外层事务结束。

建议明确：

• 每个进入 Package/plugin 的调用持有 transient activity lease；最后一个外部 handle 在 activity 内释放时只原子转为 Stopping，实际 quit/wait 延迟到该 activity 退出后执行；

• 或明确这种 last-release 只能排队异步 teardown，绝不能在被等待的执行上下文中同步 wait；

• Loader 调用 provider/user code或阻塞 wait 时，不得持有退出路径所需的全局事务锁；若选择禁止重入，则必须由 Runtime API 明确规定并检测；

• 延迟 teardown 期间继续保留 identity reservation，不能提前允许同身份重载。

• **处理方式：**不在 Package 格式规范中规定 transient activity lease、callback 内最后一次 release、异步 teardown 调度或 Loader 锁的可重入策略。这些属于 Runtime API 的线程、handle 与调用约束，由 Runtime 实现负责避免在被等待的执行上下文中形成 self-wait，并继续满足 wait 或执行域终止的安全后置条件。本规范不为此引入新的引用种类或可恢复隔离状态机。

2. rollback 会停止完成日志中的全部实例，却又要求 Quarantined dependent 保留并继续依赖它们

rollback 规则要求当前失败对象和完成日志中的运行时实例执行 quit / wait；隔离规则又要求 wait 失败的实例保留 dependency 引用，且明确不能继续递归卸载其依赖。两条在同一事务中会冲突：

本事务新建 P -> D
P.wait() 超时；P 仍可能执行并访问 D，故 P 进入 Quarantined 并保留 P -> D
D 也在本事务完成日志中
rollback 继续按 L409 对 D 执行 quit / wait

如果 D 成功 wait，它已经停止并释放或脱离运行时资源，但 P 的未静默活动仍可能调用 D。保留引用只能防止对象/插件被卸载，不能把已经 quit 的 D 恢复为可用状态；若随后再按日志清理 D 的 Acquire 产物，风险会进一步升级为悬空访问。这也直接违背“不能继续递归卸载其依赖”的后置条件。

建议 rollback 按 dependency 逆拓扑和当前引用状态推进：一旦某个 dependent 无法 quiesce，它仍可能访问的 ImportBinding、dependency 和 provider plugin 都不得再 quit/destroy。未 Commit 的所需闭包应进入不可发布但占据 identity 的 RetainedByQuarantine状态；只有 dependent 后续 wait 成功并销毁、相应边被释放且 dependency 真正归零后，才能开始停止该 dependency。L409 的“完成日志中的运行时实例”应明确排除仍被未静默 dependent 保留的实例。

• **处理方式：**该反例的前提不成立。规范现已明确 Commit 是新实例进入可执行状态的唯一边界；Commit 前的模块、资源与 ImportBinding 不得接收运行时调用、启动线程或异步任务、注册事务外 callback，provider 验证也必须同步完成。因此未 Commit 的 P 不可能存在仍在调用 D 的 worker，rollback 对本事务新建对象直接按完成日志反序销毁，不调用 quit / wait。只有此前已 Commit 且因释放临时引用而归零的实例才走正常卸载协议；RetainedByQuarantine状态无需引入。

P1：重要问题

3. Stopping / Quarantined没有宿主侧 ingress gate，旧 handle 可能继续提交新工作

quit只是“请求”停止接收新工作；wait 失败后的条款只说实例对 Loader 不可见并保留资源。只有 wait 成功时，正文才保证遗留 runtime handle 已失效。

因此 quit报错、wait超时、P 进入 Quarantined 后，调用方继续用旧 task/session handle 调 start()时，一种实现会进入隐藏实例，另一种会拒绝。前者还能不断产生新活动，使后续重试 wait 永远无法成功。

建议在 Running -> Stopping转换时，先由 Runtime-owned gate 原子拒绝所有新的外部调用，再进入 provider quit；Quarantined 永久保持 gate closed，只允许既有 in-flight 活动退出及管理面的 retry quit/wait。该 gate 必须位于不会随 provider 卸载的宿主代理中。

• **处理方式：**Commit 原子打开新实例的运行时外部入口；引用归零时先将实例从Running原子切换为Stopping并关闭全部入口，再调用 quit / wait。此后所有既有 task、session、ImportBinding、导出对象及其他 handle 发起的新操作都必须在进入 Package 或 provider plugin 代码前返回错误，只允许已经进入的调用退出以及管理方执行停止和诊断。无法正常停止时终止相应执行域，入口不会重新打开。本规范规定可观察行为，不要求采用特定宿主代理或 gate 实现。

4. ImportBinding 有创建事务，但没有对称的 close / drain 卸载协议

Ready / Commit已很好地规定了 binding 的创建与原子发布；卸载规则只规定 wait 成功后销毁 binding、importer，最后释放 dependency edge。

设 P 通过 B import 一个仍被其他 Package 使用的已 Commit 目标 D，D 的线程可通过 B 向 P 投递 callback：

• 先 wait(P)、后销毁 B：若没有先撤销 D 侧入口，D 可以继续产生新 callback，P 无法 quiesce；
• wait 前直接 free B：D 已取得但尚未完成的 callback 可能访问已释放的 B。

建议规定对称生命周期：B.close/unpublish先原子拒绝双方的新调用和 callback，但保持对象存活；B.drain/wait等待双向 in-flight 归零；Package wait 覆盖其全部 binding drain；成功后才 destroy B、destroy importer，最后释放 dependency/plugin lease。共享 target 侧需要使用与创建时对称的锁、epoch、RCU/grace period 或等价机制。

• **处理方式：**ImportBinding 与 Commit 前禁止执行形成对称生命周期：Ready 创建时保持关闭，Commit 时随 owning Package 原子打开；Package 进入Stopping时先原子关闭 binding 双方的新调用与 callback，但不立即销毁。关闭前已经进入的双向调用继续退出，并由 Package 的 wait 统一等待；wait 成功或执行域终止得到确认后，才依次销毁 binding、importing module 并释放 dependency edge。未 Commit binding 从未激活，rollback 可直接销毁。本规范不要求公开独立 close / drain API，也不规定锁、epoch 或 RCU 等实现机制。

5. provider 选择结果没有绑定到已 Commit 实例和实际插件工件

noLoad选择 provider metadata，Acquire 才加载插件，且已 Commit 实例不重复 Acquire。Package 的稳定性承诺不覆盖 provider 搜索目录、metadata 或二进制。

有两个可复现分叉：

1. P@1 已经用 b.plugin Commit；插件目录随后新增排序更早的 a.plugin。新 C 依赖 P@1 时，一实现复用 P 实例记录的 b，另一实现按 noLoad 重新选择 a，但 Acquire 又实际复用旧 P/b。
2. 新实例 noLoad 读取 a.plugin metadata 后、Acquire 打开二进制前，a.plugin被替换。一实现使用已打开的工件，另一实现按路径加载替换后的代码。

建议已 Commit/Quarantined identity 的 provider 绑定成为实例状态，后续 noLoad 必须复用而不得重新发现；仅对本事务新实例执行发现，并把选中的 metadata entry 绑定到精确 artifact（打开句柄或等价 file identity），冻结到 Acquire。变化只能报告 stale/serious loading error，不得悄悄重扫或改选。这里不要求恢复持久化 Package LoadPlan。

• **处理方式：**provider 绑定定义为 module instance 的不可变状态，只在首次创建新实例时按当时的搜索路径执行 discovery。Acquire 后记录实际 provider 与 provider plugin；已 Commit Package 被复用时直接使用各 module instance 的原绑定，不重新扫描。新增插件、搜索目录或优先级变化只影响未来首次创建的新实例。插件被选中后，其元数据与二进制工件在 Runtime 销毁前不得修改、替换或删除，违反属于部署错误。
• **不处理部分：**不要求把 provider metadata 绑定到打开句柄或其他精确 artifact identity，也不增加 stale 检测。noLoad后插件文件被替换与二进制不兼容一样属于部署错误，由部署者负责；选中插件加载失败时整次加载失败，不重新扫描或改选。

6. provider plugin 强引用缺少取得、转交和共享规则

正文只在成功 wait 后释放、Quarantined 时保留处提到 provider plugin 强引用；Acquire 只写“加载插件”，没有定义 lease 何时取得、由 Package/module/backend 中谁持有，以及多个模块、Package 或 Loader 共用同一动态库时如何合并。

P.module -> x.plugin
Q.module -> x.plugin
load(P); load(Q); release(P); Q.module.call()

需要一个明确的安全不变量：在调用任何 factory/entrypoint 前取得临时 plugin lease并写入事务日志；Commit 后所有 plugin 派生对象和 backend 都由某个仍存活的 lease 覆盖；rollback 只释放本事务 lease；Quarantined 保留完整 lease 集；全部 module、ImportBinding backend 和析构函数执行完成后，最后一个 lease 才能释放。实现可自行选择进程级实例表或 OS library refcount，但不能让一个 Package 的卸载使另一个 Package 的代码指针失效。

• **处理方式：**不引入 Package、module 或 ImportBinding 级 plugin lease。provider plugin 一旦成功加载就加入 Runtime 常驻插件集合，Package rollback 和正常卸载均不卸载它，多个 Package 与 module 直接共享。plugin 只在 Runtime 整体销毁或进程退出时卸载，且必须晚于所有 plugin 派生对象的销毁。由此一个 Package 的卸载不会影响其他 Package 的 plugin 代码，代价是已加载 plugin 在 Runtime 生命周期内常驻。

7. provider 事务钩子的失败与副作用边界不足以保证原子 Commit

L403允许共享目标使用 prepare / commit / abort，但未规定 provider 的 commit hook 是否可失败：

Ready: prepare(T1), prepare(T2) 均成功
Commit: T1.commit() 已对运行时可见
Commit: T2.commit() 抛错

此时无法满足整个闭包的原子发布，也未必能用 abort 撤销已经公开的 T1。类似地，validateOptions()若预分配 session 或写缓存，随后 importer 集合验证失败，而该副作用没有形成日志步骤，rollback 也无从撤销。

建议规定所有 validation callback 只读且不得留下持久副作用；确需预留资源时必须返回立即写入日志、可 abort 的事务私有 PreparedToken。Ready/prepare 完成全部可能失败、分配或 I/O 的工作；Commit hook 必须 non-failing/noexcept，只做已准备状态的指针或 epoch publication，并与实例表发布处于同一可见性屏障。

• **处理方式：**Commit 必须不可失败，语义类似已经准备完成后的原子落盘点。所有可能失败、分配资源、执行 I/O 或产生可撤销状态的工作都必须在 Acquire / Ready 完成，保持事务私有并立即写入完成日志；验证不得留下未记录副作用。共享目标的 prepare 在 Ready 完成，abort 负责 rollback；commit hook 不得失败、分配或 I/O，只能在与实例表相同的可见性屏障中发布已准备状态。Commit 一旦开始必须完整结束，不得再返回错误或 rollback；不强制 PreparedToken、epoch 等具体实现。

8. Quarantined identity 在依赖候选中是“过滤”还是“选中后失败”未定义

候选与 greedy/no-backtracking 算法没有把实例状态列为 eligibility 条件；L428又要求拒绝重新加载相同 identity。

bar@2 (compatVersion=1) 已 Quarantined
bar@1 (compatVersion=1) 正常可用
新 Package 请求 dependency bar@1

实现可以先过滤不可重载的 bar@2 而选择 bar@1，也可以仍按最高版本选中 bar@2、随后以 IdentityQuarantined失败且不得回退。建议明确 tombstone 与候选 eligibility 的关系。若保持严格 greedy，最直接的规则是照常选中 bar@2 后失败且不回退；若希望自动降级，则应明确在排序前过滤。

• **处理方式：**取消Quarantined及 identity tombstone 后，本项不再成立。正常 quit / wait 失败时必须终止并确认 provider 所在的最小执行域；独立 worker 可以单独终止，进程内 provider 则终止宿主进程。确认终止后完成销毁和引用释放，不留下可参与后续依赖求解的隔离身份，因此不存在过滤或选中后失败的选择。

P2：建议与文字修补

9. plugin discovery 的坏元数据和文件名边界仍缺统一处理

L514-L518规定重复 triple 使整个 plugin metadata 无效，却没说明应跳过该插件还是终止本次发现。例如 a.plugin metadata 重复、b.plugin合法匹配时，两种处理会得到失败与成功。建议同时列清无法读取、JSON 无效、重复 triple、扫描中消失、非插件文件的统一政策。

此外，basename 按 Unicode 码点排序时，应说明 POSIX 非 UTF-8 文件名是跳过还是报错，并明确 basename 是否指包含扩展名的最终路径段。

• **处理方式：**采用选中前宽松、选中后严格的边界。目录项只有在元数据可读、JSON 合法、必选字段与类型正确且三元组不重复时才被视为 provider plugin；否则包括扫描期间消失在内都当作不是插件直接跳过，不进入候选，也不使 discovery 失败。合法 provider 一旦被选中，后续元数据或二进制无法读取、消失、加载失败或不一致则属于部署错误，整次加载失败且不得回退。
• **不处理部分：**不规定 POSIX 非 UTF-8 插件文件名的跨实现行为。插件目录由部署者管理，不能被当前实现识别的文件可以视为不可用；不为这种文件名扩展 discovery 状态机。basename 按通常含义指包含扩展名的最终路径段。扫描期间消失的目录项已由上条统一为选中前跳过、选中后失败。

10. wait与 dispose 对运行时资源的所有权措辞重叠

L424说 wait 成功时运行时资源已经“释放或与实例安全脱离”，L426又说此后 Loader 才销毁模块和运行时资源。建议把后置条件拆清：wait 只保证 quiescent、无未来自主/外部访问；dispose 销毁仍归实例所有的资源。Loader-exclusive teardown 是 wait 后唯一允许继续进入 provider/dependency 的同步路径，且不得再启动异步活动。

• **处理方式：**wait 收窄为纯静止屏障，只保证全部执行、binding 双向调用和其他 in-flight 调用结束，不负责释放仍归实例所有的模块或运行时资源。wait 成功后由 Loader 执行唯一允许继续进入 provider/dependency 的同步 teardown，再释放 dependency；teardown 不得重新打开入口或启动线程、异步任务和 callback。若执行域被强制终止，只清理无需重新进入该执行域的宿主侧资源。

11. ZIP 的“header 大小”应指解析 feature 后的有效值

L331-L333一面要求实际大小与 header 不符时拒绝，一面允许实现支持 data descriptor 和 ZIP64。前者若按 raw local header 字面执行，会误拒绝合法的 data-descriptor 零占位或 ZIP64 的 0xffffffff sentinel。建议改成：实际流式结果必须与“按该实现支持的 ZIP feature 解析出的 authoritative/effective CRC 与 size”一致，并按相应 feature 验证 local header、central directory、extra field 与 descriptor 的关系。

若支持 Unicode Path extra field，也可顺手明确它与 EFS/raw UTF-8 文件名谁是 authoritative；二者冲突时必须拒绝，不能让验证路径与实际写入路径来自不同字段。

• **处理方式：**不采用 effective CRC/size 等措辞，并删除 DSPK 层对 raw header、CRC、加密、多卷和大小一致性的逐项判断。ZIP64、data descriptor、Unicode Path extra field、EFS、local header、central directory、压缩方法及权威值选择完全由 ZIP 实现决定；不支持或判定归档无效时可以拒绝。DSPK 只要求最终 entry 名称是 UTF-8，并保证成功安装结果满足路径封闭、普通文件与目录、实际解压资源限制和原子安装后置条件。

12. Singer 示例路径与推荐目录仍相差一级

Singer 示例使用 ../assets/...；按推荐目录，singer.json位于 singers/singer1/，根部 assets 应写成 ../../assets/...。avatar、background、demoAudio和示例中的 configuration.dictionary都需要同步修改，或者调整推荐目录结构。

• **处理方式：**引入非多语言字符串变量而不是继续使用易错的../../。desc.json和模块声明均可用有序vars数组定义变量；每项包含name与value，只能依赖外层变量和数组中位于它之前的变量，找不到的变量展开为空字符串。${}允许嵌套并从最内层开始展开。内置${root}指向 Package root，${dir}指向当前声明目录，Package 变量对全部模块可见，Module 变量只在当前模块生效并可覆盖同名 Package 变量。规范不强制最终内存对象是否保留vars，但交付给后续阶段的字符串必须已完全展开并可直接使用，推荐构造最终对象后移除vars。示例在desc.json定义${assets}，Singer 模块定义${singerAssets}并统一引用 avatar、background、demoAudio 与 dictionary；推荐布局增加assets/singer1/目录并与示例保持一致。

总体上，这一版已经从“解析与求解规则不闭合”推进到了“销毁与隔离边界需要最后闭环”的阶段。建议优先处理两个 P0，以及 P1 #3–#5；它们共同决定合法回调路径能否完成卸载、隔离实例是否真正停止接收工作，以及 noLoad 选中的 provider 是否就是最终执行的那份代码。

[yqzhishen]

第五轮复审（5eefd1e）

本轮基线为 docs/ds-spec-2.4.md@5eefd1e，并已逐项核对第四轮处理说明。范围仍只限规范本身；refactor是待重构的旧实现，未实现新规范不计为风险。

先确认处置结果：上一轮的 rollback / Quarantined 冲突、Stopping ingress、ImportBinding close/drain、provider 固定绑定、plugin 保活、Commit 不可失败以及 wait/dispose 分工均已在正文闭合。坏 provider metadata 的跳过规则和 Singer 示例也已修正。self-wait 被明确划给单独的 Runtime API；本轮不把这一已声明的跨规范责任重复列作本规范的新 P0，但 companion Runtime API 最终仍需给出可引用的规范性约束。

P0：无新增阻塞项

本轮没有发现新的、仅按本规范即可必然触发内存安全破坏或确定性死锁的 P0。新增问题主要来自字符串变量语言及执行域失败传播，按实现分叉和架构返工风险列为 P1。

P1：重要问题

1. 字符串变量没有唯一的 tokenization 与求值算法

变量规则定义了嵌套引用和 $$，但没有说明替换产生的新 ${...}是否再次扫描：

{
  "vars": [
    { "name": "d", "value": "$" },
    { "name": "target", "value": "foo" }
  ],
  "id": "${d}{target}"
}

按原字符串先构造 template AST、仅求值一次，结果是字面 ${target}；按字符串反复替换直到稳定，结果是 foo。$${target}以及变量值自身包含转义引用时也有同样分叉。

另外还有两个 bootstrap 边界：

• “所有 JSON 字符串值”字面上包含 vars[].name。name:"${n}"应先按 var-name拒绝，还是展开后定义另一个变量，没有规定。
• $version必须在解析其余字段前检查，但它也是字符串值。"$version":"${fmt}"可被实现 A 在展开前拒绝，也可被实现 B 展开为 1.0后接受；未来格式版本会形成真正的语法 bootstrap 循环。

建议给出正式 template grammar 和一次性算法：先读取未经展开的 $version与 vars[].name；name 永不展开；对原始字符串只 token 化一次；替换 payload 不重新解释为 template；$$产生带 literal 语义的 $；只有原 AST 中显式嵌套的引用参与内到外求值；dynamic name 求值后必须匹配 var-name，否则明确 reject 或按 missing 处理。整个展开应由一个确定层完成一次，不能由 framework/category/variant 分层重复展开。

2. “普通字符串变量”与“变量携带声明作用域路径基准”无法组合

L82-L95一方面允许变量与任意文本组合，另一方面要求路径中的 Package/Module 变量分别按各自声明作用域定基。设 Package root 为 /pkg，模块目录为 /pkg/mod：

// desc.json
"vars": [{ "name": "p", "value": "assets" }]

// mod/singer.json
"vars": [{ "name": "m", "value": "local" }],
"avatar": "cache/${p}/${m}/a.png"

p应相对 /pkg，m应相对 /pkg/mod，但一个最终路径无法同时服从两个独立基准。纯文本替换再按使用处定基会得到 /pkg/mod/cache/assets/local/a.png；携带声明 provenance 又会在路径中间产生 root anchor 与 module anchor，规范没有定义前缀丢弃、重定基还是拒绝。x/${root}/a和${root}/${dir}/a同样没有唯一含义。

这还与 Package identity 有交叉问题：变量允许出现在任意普通字符串中，${root}/${dir}也没有限定为 path。相同字节和相对布局的 P@1 安装在 /a/P与 /b/P时，如果 variant 把 configuration.cacheKey定义为普通字符串，"cacheKey":"${root}"会得到不同语义；这破坏了同身份内容承诺下缓存与重读输入应等价的前提。

最简单的闭合方式是让自定义变量始终只是纯文本，最终路径一律按使用字段所在声明定基；跨目录只能显式使用 ${root}或${dir}。两个锚点只允许出现在 schema 标记为 path 的字段中、只能位于字符串开头且最多一个。若确实要让每个变量携带自己的基准，则需要定义 path-typed value、锚点传播与多锚点组合/拒绝规则，不能仍把它描述为普通字符串替换。

3. 现有资源限制没有覆盖展开后的指数膨胀

JSON profile 的资源限制针对输入字节、节点和源字符串；变量规则没有要求限制展开后的输出或 substitution work：

{ "name": "v0", "value": "x" },
{ "name": "v1", "value": "${v0}${v0}" },
{ "name": "v2", "value": "${v1}${v1}" },
// ...
{ "name": "v40", "value": "${v39}${v39}" }

约 2 KiB 的声明即可要求物化约 1 TiB 字符串。即使 Package 被视为受信任内容，解析器也不应在发现超限前先完成巨大分配。

建议允许阈值继续由实现定义，但必须在分配/复制前执行 post-expansion 单字符串字节数、整份声明总输出、引用嵌套深度、总替换次数或总 work budget；任一超限使声明无效。规范还应说明这些限制同时覆盖变量定义的中间结果，而不只覆盖最终字段。

4. Ready 对已 Commit target 的管理调用被同时要求和禁止

Ready要求被引用 target provider 同步验证 options；shared-target 规则还允许在 Ready 调用 prepare。但 L427又禁止 Commit 前“向已 Commit 实例发送调用”。

最小场景是新 P import 已 Running 的 D，D 需要为该 binding 验证 options并预留 route/slot。D.validate/prepare()究竟是 L427 禁止的调用，还是 L422/L435要求的调用，目前没有合法唯一答案。

建议把 L427 收窄为禁止 data-plane/runtime 调用，显式允许由 Loader 发起、同步完成、事务私有且写入完成日志的 lifecycle/management validation 与 prepare 调用；此类调用应受 target 的 activity lease 和事务串行保护。若不允许任何 target 调用，则应删除 shared-target prepare 路径，要求 binding 完全由宿主侧不可变对象实现。

5. 强制终止共享执行域时，其他 Running 实例没有失败传播规则

执行域终止规则允许 Runtime 终止独立 worker 后继续运行；常驻 plugin 规则又明确允许多个 Package/module 共享 plugin，且没有要求 worker 独占一个实例：

P、Q 均已 Commit，共用 provider worker W
release(P)，P.wait 失败
Runtime 终止 W，并只清理 P
Q 仍标记 Running、入口仍打开、handle 仍有效，但 provider 状态已经消失

Q 的下一次调用是返回 transport error、自动重建 worker、转 Failed，还是继续使用失效 backend，正文没有答案。一个 Package 含有分布在多个域的 provider 时，“终止包含该 provider 的最小执行域”也没有说明应从哪个失败 activity 计算影响闭包。

建议把 execution domain 设为一等生命周期对象，记录 domain generation 及其全部 Package/module/ImportBinding/handle 成员。终止前原子关闭所有受影响实例的 ingress、失效旧 generation handle并把整个域的成员转入 Fatal/Stopping，确认域退出后统一清理宿主代理与引用。更简单的方案是禁止一个 worker 承载生命周期独立的实例；最保守的方案则是 domain fatal 直接 poison 并销毁整个 Runtime。

6. shared-target 的 abort 失败仍可能留下损坏但 Running 的 target

shared-target prepare/abort要求 rollback 可撤销；rollback又把所有 rollback/销毁错误只当附加诊断并继续：

D 已 Commit，且另一个 root handle 继续保活 D
P.Ready -> D.prepare(B)，D 保存 reservation/token
后续 Ready 失败
D.abort(B) 失败
Loader 继续销毁 B/P；D 仍为 Running

D 可能残留指向已销毁事务对象的内部状态，或至少永久占用 route/capacity。若“abort 必须能撤销”意在规定它不可失败，应把这一点明确写成 no-fail 后置条件，并排除在 L451 的普通 rollback error 之外。

建议把回滚拆成不可失败的逻辑 detach 与可失败的物理资源回收：先从 shared target 中删除所有指针、registration 和可遍历状态；后续释放 OS/device 资源失败才只作诊断。若无法证明逻辑 detach 成功，D 及其 execution-domain closure 必须进入停止/终止流程，不能继续保持 Running，也不能先销毁它可能引用的事务对象。

P2：精确修文

7. never-active rollback 与“唯一 teardown 路径”字面冲突

L443要求 rollback 进入 provider 直接销毁未 Commit 的 Acquire/Ready 产物；L466却说“wait 后的销毁是唯一仍可进入 provider 或 dependency 代码的 teardown 路径”。建议把“唯一”限缩为“对已 Commit 实例的正常卸载而言唯一”，并明确 never-active rollback 是另一条无需 wait 的同步 provider teardown。

8. 只有最终 wait barrier 失败才应触发执行域终止

quit 明确不构成停止证明，L468却写“quit 或 wait 无法正常证明”就终止执行域。按字面，正常的异步 quit 本来就不能证明停止，也会进入强杀。

建议明确状态表：quit error + wait(Quiescent)仍正常 teardown，quit error 只作诊断；只有 wait(Failed/Timeout/Unavailable)或根本无法执行最终 barrier 时才终止执行域。

9. Inference metadata 的 apiLevel与通用字段 level不一致

通用 provider metadata要求三元组字段 interface / variant / level；Inference 专章则写 apiLevel。通用 validator 可以把只含 apiLevel的 inference plugin 判为缺少必选字段。建议统一字段名，或明确 apiLevel就是 inference category 对通用 level槽位的序列化名称。

10. 选中后的插件错误政策应区分“已观测错误”和“未监测变更”

L565要求选中后 metadata/binary 消失或不一致时整次加载失败；紧接着又说同类修改属于行为未定义，Runtime 不监视或检测。建议把前者限定为 Runtime 在正常 read/load 中实际观测到无法读取、加载失败或不一致时必须失败；没有被检测的部署期修改统一适用后者的 undefined policy。

11. multi-volume ZIP 与单个 .dspk分发单元不一致

Package 被定义为单个 dspk ZIP 文件，安装入口也只接收一个 dspk；L359却允许实现支持 multi-volume ZIP。分卷归档需要多个文件及卷发现/命名规则，单个 .dspk不再是完整最小分发单元。若确实允许，应定义辅助卷如何归属于 Package、如何定位并随同安装；否则从可选 feature 列表删除 multi-volume 即可。

总体上，本轮的主问题已经不是旧加载算法，而是新引入的宏语言和执行域模型需要收紧边界。建议先处理 P1 #1、#2、#4、#5：它们分别决定同一清单能否唯一展开、路径是否仍有单一语义、Ready 是否存在合法调用路径，以及强杀 worker 后 Runtime 是否还能保持一致状态。

[SineStriker]

第五轮复审（5eefd1e）

本轮基线为 docs/ds-spec-2.4.md@5eefd1e，并已逐项核对第四轮处理说明。范围仍只限规范本身；refactor是待重构的旧实现，未实现新规范不计为风险。

先确认处置结果：上一轮的 rollback / Quarantined 冲突、Stopping ingress、ImportBinding close/drain、provider 固定绑定、plugin 保活、Commit 不可失败以及 wait/dispose 分工均已在正文闭合。坏 provider metadata 的跳过规则和 Singer 示例也已修正。self-wait 被明确划给单独的 Runtime API；本轮不把这一已声明的跨规范责任重复列作本规范的新 P0，但 companion Runtime API 最终仍需给出可引用的规范性约束。

P0：无新增阻塞项

本轮没有发现新的、仅按本规范即可必然触发内存安全破坏或确定性死锁的 P0。新增问题主要来自字符串变量语言及执行域失败传播，按实现分叉和架构返工风险列为 P1。

P1：重要问题

1. 字符串变量没有唯一的 tokenization 与求值算法

变量规则定义了嵌套引用和 $$，但没有说明替换产生的新 ${...}是否再次扫描：

{
  "vars": [
    { "name": "d", "value": "$" },
    { "name": "target", "value": "foo" }
  ],
  "id": "${d}{target}"
}

按原字符串先构造 template AST、仅求值一次，结果是字面 ${target}；按字符串反复替换直到稳定，结果是 foo。$${target}以及变量值自身包含转义引用时也有同样分叉。

另外还有两个 bootstrap 边界：

• “所有 JSON 字符串值”字面上包含 vars[].name。name:"${n}"应先按 var-name拒绝，还是展开后定义另一个变量，没有规定。
• $version必须在解析其余字段前检查，但它也是字符串值。"$version":"${fmt}"可被实现 A 在展开前拒绝，也可被实现 B 展开为 1.0后接受；未来格式版本会形成真正的语法 bootstrap 循环。

建议给出正式 template grammar 和一次性算法：先读取未经展开的 $version与 vars[].name；name 永不展开；对原始字符串只 token 化一次；替换 payload 不重新解释为 template；$$产生带 literal 语义的 $；只有原 AST 中显式嵌套的引用参与内到外求值；dynamic name 求值后必须匹配 var-name，否则明确 reject 或按 missing 处理。整个展开应由一个确定层完成一次，不能由 framework/category/variant 分层重复展开。

• **处理方式：**规定每个原始 JSON 字符串只进行一次 tokenization 和求值，替换结果不再扫描，只有原始字符串中显式存在的嵌套引用由内到外求值；$${target}及由替换拼出的${target}均保留为字面结果。各层级的$version和vars[].name按未经展开的原始值验证且不得包含变量引用。Loader 在交付声明前统一完成展开，后续 framework、category、interface 或 variant 不得重复展开。

2. “普通字符串变量”与“变量携带声明作用域路径基准”无法组合

L82-L95一方面允许变量与任意文本组合，另一方面要求路径中的 Package/Module 变量分别按各自声明作用域定基。设 Package root 为 /pkg，模块目录为 /pkg/mod：

// desc.json
"vars": [{ "name": "p", "value": "assets" }]

// mod/singer.json
"vars": [{ "name": "m", "value": "local" }],
"avatar": "cache/${p}/${m}/a.png"

p应相对 /pkg，m应相对 /pkg/mod，但一个最终路径无法同时服从两个独立基准。纯文本替换再按使用处定基会得到 /pkg/mod/cache/assets/local/a.png；携带声明 provenance 又会在路径中间产生 root anchor 与 module anchor，规范没有定义前缀丢弃、重定基还是拒绝。x/${root}/a和${root}/${dir}/a同样没有唯一含义。

这还与 Package identity 有交叉问题：变量允许出现在任意普通字符串中，${root}/${dir}也没有限定为 path。相同字节和相对布局的 P@1 安装在 /a/P与 /b/P时，如果 variant 把 configuration.cacheKey定义为普通字符串，"cacheKey":"${root}"会得到不同语义；这破坏了同身份内容承诺下缓存与重读输入应等价的前提。

最简单的闭合方式是让自定义变量始终只是纯文本，最终路径一律按使用字段所在声明定基；跨目录只能显式使用 ${root}或${dir}。两个锚点只允许出现在 schema 标记为 path 的字段中、只能位于字符串开头且最多一个。若确实要让每个变量携带自己的基准，则需要定义 path-typed value、锚点传播与多锚点组合/拒绝规则，不能仍把它描述为普通字符串替换。

• **处理方式：**原正文把变量查找作用域误写成了路径定基规则，并非设计要求。现已明确自定义变量只携带字符串内容，作用域只决定变量查找；路径字段先完成整个字符串的变量展开，再统一以该字段所在声明文件的目录为基准解析。${root}与${dir}仍是 Runtime 提供的特殊字符串变量，不为普通变量引入路径 provenance。

3. 现有资源限制没有覆盖展开后的指数膨胀

JSON profile 的资源限制针对输入字节、节点和源字符串；变量规则没有要求限制展开后的输出或 substitution work：

{ "name": "v0", "value": "x" },
{ "name": "v1", "value": "${v0}${v0}" },
{ "name": "v2", "value": "${v1}${v1}" },
// ...
{ "name": "v40", "value": "${v39}${v39}" }

约 2 KiB 的声明即可要求物化约 1 TiB 字符串。即使 Package 被视为受信任内容，解析器也不应在发现超限前先完成巨大分配。

建议允许阈值继续由实现定义，但必须在分配/复制前执行 post-expansion 单字符串字节数、整份声明总输出、引用嵌套深度、总替换次数或总 work budget；任一超限使声明无效。规范还应说明这些限制同时覆盖变量定义的中间结果，而不只覆盖最终字段。

• **处理方式：**不采纳，不在本规范中为变量展开另设输出长度、替换次数或工作量预算。资源限制及其检查时机由实现决定；极端或恶意变量定义造成的长时间计算、内存耗尽或加载失败不属于本规范保证，Package 作者应避免此类写法。

4. Ready 对已 Commit target 的管理调用被同时要求和禁止

Ready要求被引用 target provider 同步验证 options；shared-target 规则还允许在 Ready 调用 prepare。但 L427又禁止 Commit 前“向已 Commit 实例发送调用”。

最小场景是新 P import 已 Running 的 D，D 需要为该 binding 验证 options并预留 route/slot。D.validate/prepare()究竟是 L427 禁止的调用，还是 L422/L435要求的调用，目前没有合法唯一答案。

建议把 L427 收窄为禁止 data-plane/runtime 调用，显式允许由 Loader 发起、同步完成、事务私有且写入完成日志的 lifecycle/management validation 与 prepare 调用；此类调用应受 target 的 activity lease 和事务串行保护。若不允许任何 target 调用，则应删除 shared-target prepare 路径，要求 binding 完全由宿主侧不可变对象实现。

• **处理方式：**将调用明确分为管理调用与运行时调用。Loader 可以在加载事务的相应阶段对新实例或已 Commit 的目标实例同步执行验证及 prepare / commit / abort 等管理调用；管理调用必须在返回前完成，不得启动异步活动，失败按加载事务或 rollback 规则处理。Commit 前禁止的是合成、推理、音频处理等运行时业务调用，因此 Ready 对已 Commit target 的验证和准备不再与 Commit 边界冲突。

5. 强制终止共享执行域时，其他 Running 实例没有失败传播规则

执行域终止规则允许 Runtime 终止独立 worker 后继续运行；常驻 plugin 规则又明确允许多个 Package/module 共享 plugin，且没有要求 worker 独占一个实例：

P、Q 均已 Commit，共用 provider worker W
release(P)，P.wait 失败
Runtime 终止 W，并只清理 P
Q 仍标记 Running、入口仍打开、handle 仍有效，但 provider 状态已经消失

Q 的下一次调用是返回 transport error、自动重建 worker、转 Failed，还是继续使用失效 backend，正文没有答案。一个 Package 含有分布在多个域的 provider 时，“终止包含该 provider 的最小执行域”也没有说明应从哪个失败 activity 计算影响闭包。

建议把 execution domain 设为一等生命周期对象，记录 domain generation 及其全部 Package/module/ImportBinding/handle 成员。终止前原子关闭所有受影响实例的 ingress、失效旧 generation handle并把整个域的成员转入 Fatal/Stopping，确认域退出后统一清理宿主代理与引用。更简单的方案是禁止一个 worker 承载生命周期独立的实例；最保守的方案则是 domain fatal 直接 poison 并销毁整个 Runtime。

• **处理方式：**不采用“终止共享 worker 后令其他 Running 实例一起失败”的传播方式。只要 worker 仍承载其他有有效引用的实例，Runtime 就不得因单个实例卸载失败而终止该唯一可用 worker。跨进程 provider 必须提供实例级故障隔离或等价恢复能力，可以通过独立 worker、多 worker、多节点、心跳、握手、重发、状态恢复或实例重建等机制实现；一个实例失败不得使其他独立实例永久失效。无法提供该保证的 provider 不得在同一故障域内共享承载生命周期独立的实例。同进程且无法进一步隔离时仍按 fail-fast 处理。

6. shared-target 的 abort 失败仍可能留下损坏但 Running 的 target

shared-target prepare/abort要求 rollback 可撤销；rollback又把所有 rollback/销毁错误只当附加诊断并继续：

D 已 Commit，且另一个 root handle 继续保活 D
P.Ready -> D.prepare(B)，D 保存 reservation/token
后续 Ready 失败
D.abort(B) 失败
Loader 继续销毁 B/P；D 仍为 Running

D 可能残留指向已销毁事务对象的内部状态，或至少永久占用 route/capacity。若“abort 必须能撤销”意在规定它不可失败，应把这一点明确写成 no-fail 后置条件，并排除在 L451 的普通 rollback error 之外。

建议把回滚拆成不可失败的逻辑 detach 与可失败的物理资源回收：先从 shared target 中删除所有指针、registration 和可遍历状态；后续释放 OS/device 资源失败才只作诊断。若无法证明逻辑 detach 成功，D 及其 execution-domain closure 必须进入停止/终止流程，不能继续保持 Running，也不能先销毁它可能引用的事务对象。

• **处理方式：**将 abort 拆分为不可失败的逻辑撤销与允许失败的物理资源回收。逻辑撤销必须先移除共享目标中的 binding、registration、指针及所有可访问或可遍历的事务状态，保证目标不再引用将被销毁的对象；后续文件、设备等物理资源回收失败只作为附加诊断。逻辑撤销失败属于 provider fatal error，同进程 provider 必须 fail-fast，跨进程 provider 按实例隔离或恢复规则处理，不得让可能损坏的 target 继续作为正常 Running 实例使用。

P2：精确修文

7. never-active rollback 与“唯一 teardown 路径”字面冲突

L443要求 rollback 进入 provider 直接销毁未 Commit 的 Acquire/Ready 产物；L466却说“wait 后的销毁是唯一仍可进入 provider 或 dependency 代码的 teardown 路径”。建议把“唯一”限缩为“对已 Commit 实例的正常卸载而言唯一”，并明确 never-active rollback 是另一条无需 wait 的同步 provider teardown。

• **处理方式：**将“唯一 teardown 路径”限于已经 Commit 实例的正常卸载。未 Commit 且从未激活的 Acquire / Ready 产物明确按 rollback 完成日志直接执行同步 provider teardown，不调用 quit 或 wait；两条路径都不得启动新的异步活动。

8. 只有最终 wait barrier 失败才应触发执行域终止

quit 明确不构成停止证明，L468却写“quit 或 wait 无法正常证明”就终止执行域。按字面，正常的异步 quit 本来就不能证明停止，也会进入强杀。

建议明确状态表：quit error + wait(Quiescent)仍正常 teardown，quit error 只作诊断；只有 wait(Failed/Timeout/Unavailable)或根本无法执行最终 barrier 时才终止执行域。

• **处理方式：**明确 quit 错误只作为卸载诊断，Runtime 无论如何仍执行最终 wait barrier；wait 成功即按正常路径 teardown。只有 wait 失败、超时、不可用或无法执行，不能证明实例已经停止时，才进入执行域终止流程。

9. Inference metadata 的 apiLevel与通用字段 level不一致

通用 provider metadata要求三元组字段 interface / variant / level；Inference 专章则写 apiLevel。通用 validator 可以把只含 apiLevel的 inference plugin 判为缺少必选字段。建议统一字段名，或明确 apiLevel就是 inference category 对通用 level槽位的序列化名称。

• **处理方式：**Inference provider metadata 统一使用通用字段名level，三元组统一为 (interface, variant, level)，不再使用apiLevel。API Level 与 Runtime Level 都是各自作用域内的 level；runtimeLevel因表示 Package 对核心运行时能力等级的要求而保留其字段名。

10. 选中后的插件错误政策应区分“已观测错误”和“未监测变更”

L565要求选中后 metadata/binary 消失或不一致时整次加载失败；紧接着又说同类修改属于行为未定义，Runtime 不监视或检测。建议把前者限定为 Runtime 在正常 read/load 中实际观测到无法读取、加载失败或不一致时必须失败；没有被检测的部署期修改统一适用后者的 undefined policy。

• **处理方式：**把加载失败规则限定为 Runtime 在正常读取或加载过程中实际观测到的无法读取、消失、加载失败或不一致。Runtime 未监测到的部署期修改仍适用下一段的行为未定义规则，不要求额外监视、快照或 stale 检查。

11. multi-volume ZIP 与单个 .dspk分发单元不一致

Package 被定义为单个 dspk ZIP 文件，安装入口也只接收一个 dspk；L359却允许实现支持 multi-volume ZIP。分卷归档需要多个文件及卷发现/命名规则，单个 .dspk不再是完整最小分发单元。若确实允许，应定义辅助卷如何归属于 Package、如何定位并随同安装；否则从可选 feature 列表删除 multi-volume 即可。

• **处理方式：**明确 DSPK 是 ZIP 格式的单文件分发单元，不得依赖辅助卷或其他分卷文件；从实现可选 ZIP 特性列表中删除多卷，仅保留不依赖辅助卷的实现自定特性。

总体上，本轮的主问题已经不是旧加载算法，而是新引入的宏语言和执行域模型需要收紧边界。建议先处理 P1 #1、#2、#4、#5：它们分别决定同一清单能否唯一展开、路径是否仍有单一语义、Ready 是否存在合法调用路径，以及强杀 worker 后 Runtime 是否还能保持一致状态。

[yqzhishen]

第六轮复审（ac0d562）

本轮基线为 docs/ds-spec-2.4.md@ac0d562，并已逐项核对第五轮处理说明。范围仍只限规范本身；refactor 是待重构的旧实现，未实现新版规范不计为风险。

先确认本次进展：变量的单次 tokenization、替换结果不重扫、$version / vars[].name bootstrap、Ready 管理调用、逻辑 abort 的 no-fail 要求、正常卸载与 never-active rollback 的 teardown 分工、quit / wait 判据、provider 元数据字段及工件稳定性均已补齐。展开资源预算、JSONC 边界、ZIP feature 集等也已被明确设为产品取舍，本轮不再重复。

P0：无新增阻塞项

本轮没有发现新的、仅按本规范即可在正常合规路径上必然触发内存破坏或确定性死锁的 P0。下面的 P1 包括一个正常输入解释分叉，以及两个规范已经选择处理、但尚未完全闭合的 provider 异常路径；一般的超时归属和语法边角降为 P2。

P1：重要问题

1. ${root} / ${dir} 在纯字符串模型中缺少可实现的传播与校验规则

路径与变量规则同时规定：

• 相对路径字段不得使用绝对路径；
• 自定义变量只携带字符串内容，不携带路径基准；
• ${root} / ${dir} 是逻辑路径锚点；
• 后续阶段只接收已经展开的普通字符串。

但官方示例恰好要求锚点跨自定义变量传播，Singer 又把它继续传到类别路径字段和 variant-defined configuration：

Package root = C:\pkg
assets       = ${root}/assets
singerAssets = ${assets}/singer1
dictionary   = ${singerAssets}/dsdict.json

若 ${root} 在变量求值时变成物理路径，最终值是 C:\pkg\assets\singer1\dsdict.json。只看最终字符串的实现会按相对路径规则拒绝它；接受官方示例的实现则必须额外保留一种正文尚未定义的 anchor 语义，不能从最终字符串反推出其来源。对 readme、avatar等明确的路径字段已经会产生分叉；对由 variant 定义的 configuration.dictionary，Loader 甚至未必预先知道该字段是否是路径。若宽免所有由变量生成的绝对路径，则下面写法又可以绕过绝对路径禁令：

{
  "vars": [{"name":"p", "value":"C:/outside"}],
  "avatar":"${p}/avatar.png"
}

把 anchor 留成字面 ${root} 也不成立，因为 $${root} 已被明确规定应产生同样字面的普通文本，不能随后又被路径层解释为 anchor。x/${root}/a 与 ${root}/${dir}/a 的前缀和双锚点语义也未定义。

建议二选一：

• 将 root / dir 定义为带类型的 opaque path-anchor token，使其能跨变量替换保留；同时要求 category / variant schema 向 Loader 暴露 path-typed 字段，最终只在这些字段中解析 anchor；每个最终路径最多一个 anchor，且只能位于开头；或
• 保持变量为纯文本，但禁止在 vars[].value 中保存 anchor，只允许最终 path template 直接以 ${root} 或 ${dir} 开头。

无论选择哪种，都应明确 anchor 的可用字段；若它被限定为路径能力，就应禁止在普通文本字段中使用，并明确 escaped $${root} 永远只是文字。

2. abort-fatal 分支未明确先于普通 rollback 成为安全屏障

shared target 的 prepare / commit / abort 规则已正确要求逻辑 abort 不可失败；失败规则也把违反该要求定义为 provider fatal。不过，普通 rollback 流程仍要求按完成日志反序销毁事务对象并释放临时引用，正文没有明确 L462 的 fatal 分支应覆盖并暂停 L454 的普通流程。

最小反例：

D 已 Commit，且被其他 Package 保活
P.Ready -> D.prepare(B)，D 保存了指向 B/P 的事务私有状态
后续 Ready 失败
D.abort 未能完成逻辑 detach

如果一种实现先继续普通 rollback、而跨进程的隔离 / 恢复尚未完成，损坏的 D 仍可能访问已销毁的 B / P。仅把 D 标成 fatal 并异步恢复，不能建立销毁安全性。

建议明确 fatal rollback barrier 覆盖普通反序清理：立即关闭受影响 ingress，并保留 shared target 仍可能访问的事务对象和引用；只有执行域已经终止，或恢复过程已证明 shared target 不再保存本事务的任何 pointer / registration 后，才可继续 rollback。同进程 fail-fast 不会返回；跨进程隔离的完成证明必须是 rollback 继续执行的前置条件。

3. “实例级隔离”没有定义共享 target 上单条 binding activity 的失败闭包

Package / module 共享规则允许多个依赖方共享同一 target 实例；执行域规则则以“实例”和“worker / 节点”为隔离单位。ImportBinding / request 上的 activity 卡死时，这两种粒度并不足以给出唯一动作：

P -> Bp -> D
Q -> Bq -> D       // P、Q 共享同一个 D 实例

Bp 的调用已经进入 D 并卡死
release(P) -> close(Bp) -> wait(P) 等待该调用
D 仍被 Q 强引用，Bq 正常使用

终止 D 会影响 Q；不终止又无法证明 Bp 已停止。L481 对“多个生命周期相互独立的实例”的隔离 / 恢复承诺，没有说明同一个 D 实例上的两条 binding activity 如何分离，也没有规定恢复 D 后既有 Bq / handle 如何与新 generation 重新绑定。

建议把故障闭包定义到 binding / request generation：能够单独取消并证明某条 binding 的 activity 不再访问其 owner时，只终止该 activity；做不到时，明确沿共享 target 的哪些反向 binding / dependency 关闭 ingress，并规定恢复后的 instance / binding / handle generation 如何原子切换。具体状态可以留给 Runtime API，但本规范至少要给出 Package / ImportBinding 层面的保活与销毁后置条件。

P2：澄清与示例

4. wait 后 teardown 的超时 / 失联责任边界未写明

卸载规则在 wait 成功后仍允许 Loader 进入 provider / dependency 代码同步销毁 binding、module 和资源；执行域强制终止则只明确以最终 wait barrier 失败为必选触发条件。规范没有承诺 teardown 有限时间，所以这不升 P1；但最好说明 teardown 调用超时、worker 失联或崩溃由本规范还是 Runtime API 定义。若实现选择超时终止，在确认 teardown 代码不再执行前，同样不得销毁当前对象或释放其 dependency，并应复用上面的 fatal barrier。

5. 动态变量名求值为非法值或空串时的处理仍可分叉

嵌套引用规则允许 ${${selector}}，但没有明确内层结果不匹配 var-name（或为空）时，是声明无效，还是按 lookup miss 展开为空：

{
  "vars": [{"name":"selector", "value":"bad-name"}],
  "description":"${${selector}}"
}

建议二选一写明：动态 name 求值后必须再次匹配 var-name，否则拒绝声明；或将非法 / 空动态 name 统一视为 missing 并展开为空。

6. 连续示例还不能组成一个可加载的 Package

desc.json 示例给本包声明的 inference ID 是 pitch、variance；Singer 示例却引用本包的 acoustic-1、variance-A；推荐目录树又只展示 acoustic、duration。

Singer 示例会使用 desc.json 中定义的 ${assets}，因此这些片段看起来是在共同描述同一个 Package，却无法按原样通过 ModuleReference 绑定。建议统一 ID、路径和目录；若各代码块本来互不关联，应明确标注，并让 Singer 片段同时给出它依赖的 Package 变量。

结论

本轮最优先的是第 1 项：它不是一般的变量语法边角，而是正文示例、相对路径安全规则和 variant 分层之间的直接冲突。第 2～3 项都位于 provider 已经异常的路径，因此不升 P0；但规范既然选择定义隔离 / 恢复，而不是简单把坏 provider 行为全部列为未定义，就需要把“何时可以继续销毁”和“失败传播到哪些对象”补成闭合协议。第 4～6 项是低成本的责任边界、语法和示例修补。

[SineStriker]

第六轮复审（ac0d562）

本轮基线为 docs/ds-spec-2.4.md@ac0d562，并已逐项核对第五轮处理说明。范围仍只限规范本身；refactor 是待重构的旧实现，未实现新版规范不计为风险。

先确认本次进展：变量的单次 tokenization、替换结果不重扫、$version / vars[].name bootstrap、Ready 管理调用、逻辑 abort 的 no-fail 要求、正常卸载与 never-active rollback 的 teardown 分工、quit / wait 判据、provider 元数据字段及工件稳定性均已补齐。展开资源预算、JSONC 边界、ZIP feature 集等也已被明确设为产品取舍，本轮不再重复。

P0：无新增阻塞项

本轮没有发现新的、仅按本规范即可在正常合规路径上必然触发内存破坏或确定性死锁的 P0。下面的 P1 包括一个正常输入解释分叉，以及两个规范已经选择处理、但尚未完全闭合的 provider 异常路径；一般的超时归属和语法边角降为 P2。

P1：重要问题

1. ${root} / ${dir} 在纯字符串模型中缺少可实现的传播与校验规则

路径与变量规则同时规定：

• 相对路径字段不得使用绝对路径；
• 自定义变量只携带字符串内容，不携带路径基准；
• ${root} / ${dir} 是逻辑路径锚点；
• 后续阶段只接收已经展开的普通字符串。

但官方示例恰好要求锚点跨自定义变量传播，Singer 又把它继续传到类别路径字段和 variant-defined configuration：

Package root = C:\pkg
assets       = ${root}/assets
singerAssets = ${assets}/singer1
dictionary   = ${singerAssets}/dsdict.json

若 ${root} 在变量求值时变成物理路径，最终值是 C:\pkg\assets\singer1\dsdict.json。只看最终字符串的实现会按相对路径规则拒绝它；接受官方示例的实现则必须额外保留一种正文尚未定义的 anchor 语义，不能从最终字符串反推出其来源。对 readme、avatar等明确的路径字段已经会产生分叉；对由 variant 定义的 configuration.dictionary，Loader 甚至未必预先知道该字段是否是路径。若宽免所有由变量生成的绝对路径，则下面写法又可以绕过绝对路径禁令：

{
  "vars": [{"name":"p", "value":"C:/outside"}],
  "avatar":"${p}/avatar.png"
}

把 anchor 留成字面 ${root} 也不成立，因为 $${root} 已被明确规定应产生同样字面的普通文本，不能随后又被路径层解释为 anchor。x/${root}/a 与 ${root}/${dir}/a 的前缀和双锚点语义也未定义。

建议二选一：

• 将 root / dir 定义为带类型的 opaque path-anchor token，使其能跨变量替换保留；同时要求 category / variant schema 向 Loader 暴露 path-typed 字段，最终只在这些字段中解析 anchor；每个最终路径最多一个 anchor，且只能位于开头；或
• 保持变量为纯文本，但禁止在 vars[].value 中保存 anchor，只允许最终 path template 直接以 ${root} 或 ${dir} 开头。

无论选择哪种，都应明确 anchor 的可用字段；若它被限定为路径能力，就应禁止在普通文本字段中使用，并明确 escaped $${root} 永远只是文字。

• **处理方式：**不再限制声明中的资源路径必须是相对路径。${root}与${dir}按普通字符串变量展开并可以经由自定义变量继续传播，不需要保留 opaque anchor 或 provenance。路径字段完成全部字符串展开后，绝对路径直接使用，相对路径才以字段所在声明文件的目录为基准解析；盘符、UNC、device 前缀等交由宿主文件系统解释。ZIP entry 的绝对路径禁令仍作为安全解包规则保留。

2. abort-fatal 分支未明确先于普通 rollback 成为安全屏障

shared target 的 prepare / commit / abort 规则已正确要求逻辑 abort 不可失败；失败规则也把违反该要求定义为 provider fatal。不过，普通 rollback 流程仍要求按完成日志反序销毁事务对象并释放临时引用，正文没有明确 L462 的 fatal 分支应覆盖并暂停 L454 的普通流程。

最小反例：

D 已 Commit，且被其他 Package 保活
P.Ready -> D.prepare(B)，D 保存了指向 B/P 的事务私有状态
后续 Ready 失败
D.abort 未能完成逻辑 detach

如果一种实现先继续普通 rollback、而跨进程的隔离 / 恢复尚未完成，损坏的 D 仍可能访问已销毁的 B / P。仅把 D 标成 fatal 并异步恢复，不能建立销毁安全性。

建议明确 fatal rollback barrier 覆盖普通反序清理：立即关闭受影响 ingress，并保留 shared target 仍可能访问的事务对象和引用；只有执行域已经终止，或恢复过程已证明 shared target 不再保存本事务的任何 pointer / registration 后，才可继续 rollback。同进程 fail-fast 不会返回；跨进程隔离的完成证明必须是 rollback 继续执行的前置条件。

• **处理方式：**不采纳。规范已经要求 abort 的逻辑撤销不可失败；无法完成该要求的 provider 不合法，后续行为未定义。Runtime 不负责在 provider 已违反这一规范性前提后继续建立 rollback 安全屏障、隔离或恢复流程。允许失败的物理资源回收仍只作为附加诊断，不影响逻辑 abort 的不可失败要求。

3. “实例级隔离”没有定义共享 target 上单条 binding activity 的失败闭包

Package / module 共享规则允许多个依赖方共享同一 target 实例；执行域规则则以“实例”和“worker / 节点”为隔离单位。ImportBinding / request 上的 activity 卡死时，这两种粒度并不足以给出唯一动作：

P -> Bp -> D
Q -> Bq -> D       // P、Q 共享同一个 D 实例

Bp 的调用已经进入 D 并卡死
release(P) -> close(Bp) -> wait(P) 等待该调用
D 仍被 Q 强引用，Bq 正常使用

终止 D 会影响 Q；不终止又无法证明 Bp 已停止。L481 对“多个生命周期相互独立的实例”的隔离 / 恢复承诺，没有说明同一个 D 实例上的两条 binding activity 如何分离，也没有规定恢复 D 后既有 Bq / handle 如何与新 generation 重新绑定。

建议把故障闭包定义到 binding / request generation：能够单独取消并证明某条 binding 的 activity 不再访问其 owner时，只终止该 activity；做不到时，明确沿共享 target 的哪些反向 binding / dependency 关闭 ingress，并规定恢复后的 instance / binding / handle generation 如何原子切换。具体状态可以留给 Runtime API，但本规范至少要给出 Package / ImportBinding 层面的保活与销毁后置条件。

• **处理方式：**把 provider 的隔离要求扩展到 ImportBinding 及其调用级，但不在本规范定义 generation、迁移或恢复协议。每项活动必须归属于具体 Package，通过 binding 产生的活动还必须归属于具体 binding；关闭一条 binding 后，provider 必须能够停止、取消或隔离其既有活动，使 owning Package 的 wait 不永久破坏共享 target 上的其他 binding。在确认活动不再访问 owning Package 或 binding 前不得销毁二者。无法满足该结果的 provider 不得共享不可分割的故障单元；违反要求的 provider 不合法，后续行为未定义。

P2：澄清与示例

4. wait 后 teardown 的超时 / 失联责任边界未写明

卸载规则在 wait 成功后仍允许 Loader 进入 provider / dependency 代码同步销毁 binding、module 和资源；执行域强制终止则只明确以最终 wait barrier 失败为必选触发条件。规范没有承诺 teardown 有限时间，所以这不升 P1；但最好说明 teardown 调用超时、worker 失联或崩溃由本规范还是 Runtime API 定义。若实现选择超时终止，在确认 teardown 代码不再执行前，同样不得销毁当前对象或释放其 dependency，并应复用上面的 fatal barrier。

• **处理方式：**只规定 provider 的合规要求，不定义 teardown 超时、失联检测或补救协议。同步 teardown 必须完成并返回，不得启动异步活动，返回后不得再访问已经销毁的对象；无法完成并返回的 provider 不合法，后续行为未定义。

5. 动态变量名求值为非法值或空串时的处理仍可分叉

嵌套引用规则允许 ${${selector}}，但没有明确内层结果不匹配 var-name（或为空）时，是声明无效，还是按 lookup miss 展开为空：

{
  "vars": [{"name":"selector", "value":"bad-name"}],
  "description":"${${selector}}"
}

建议二选一写明：动态 name 求值后必须再次匹配 var-name，否则拒绝声明；或将非法 / 空动态 name 统一视为 missing 并展开为空。

• **处理方式：**采用 missing 语义。引用 payload 完成显式嵌套求值后，若为空、不匹配var-name或找不到同名变量，统一展开为空字符串；因此${}直接为空，${${var}}在内层得到bad-name时也为空，不使声明无效。

6. 连续示例还不能组成一个可加载的 Package

desc.json 示例给本包声明的 inference ID 是 pitch、variance；Singer 示例却引用本包的 acoustic-1、variance-A；推荐目录树又只展示 acoustic、duration。

Singer 示例会使用 desc.json 中定义的 ${assets}，因此这些片段看起来是在共同描述同一个 Package，却无法按原样通过 ModuleReference 绑定。建议统一 ID、路径和目录；若各代码块本来互不关联，应明确标注，并让 Singer 片段同时给出它依赖的 Package 变量。

• **处理方式：**把连续示例统一为同一个 Package。desc.json声明本地acoustic与variance模块，Singer 分别引用:inference/acoustic与:inference/variance，并继续通过已声明的bar dependency 演示外部bar:inference/pitch。推荐目录同步使用inferences/acoustic与inferences/variance，并补充assets/readme.txt以对应readme字段；Singer 段前明确说明它与本章desc.json属于同一示例。

结论

本轮最优先的是第 1 项：它不是一般的变量语法边角，而是正文示例、相对路径安全规则和 variant 分层之间的直接冲突。第 2～3 项都位于 provider 已经异常的路径，因此不升 P0；但规范既然选择定义隔离 / 恢复，而不是简单把坏 provider 行为全部列为未定义，就需要把“何时可以继续销毁”和“失败传播到哪些对象”补成闭合协议。第 4～6 项是低成本的责任边界、语法和示例修补。

[yqzhishen]

第七轮复审（d690be3）

本轮基线为 docs/ds-spec-2.4.md@d690be3，并已逐项核对第六轮处理说明。范围仍只限规范本身；refactor 是待重构的旧实现，未实现新版规范不计为风险。

先确认处理结果：第六轮的变量 anchor 问题已通过允许绝对资源路径改成另一套明确设计；abort 与 teardown 违约后的行为被明确设为未定义；动态变量名、示例 ID / 目录以及 ImportBinding / 调用级隔离要求也都已补入正文。本轮不重新争论这些产品取舍，只检查新文字能否彼此闭合。

P0：无新增阻塞项

没有发现新的 P0。本轮只有一处会使卸载与故障隔离产生不同架构实现的 P1；其余是低成本的路径表示、字段默认值和示例澄清。

P1：重要问题

1. isolate 与 wait 的“全部活动已停止”后置条件不一致

新增的 ImportBinding 隔离规则允许 provider 对某条 binding 的既有活动执行“停止、取消或隔离”，并把安全销毁门槛定义为这些活动不再访问 owning Package 或 binding；但 wait 的后置条件又要求“由该 Package 实例产生的所有执行活动均已停止”。

最小反例：

P 经 ImportBinding B 调用共享 target D，启动不可取消的远端 / GPU 计算 K
close(B)
provider 撤销 K 的 callback 与结果通道，并原子清除 K 对 P / B 的全部访问
K 继续只使用 D 自身状态运行

按 L434，K 已被成功隔离，P / B 可以在不破坏其他 binding 的情况下进入安全销毁；按 L467，K 历史上仍是“由 P 产生”的活动且尚未停止，P.wait()不能成功。于是实现会分成两类：

• isolate等同于逻辑完成 / 所有权转移，P 可以正常卸载；
• 必须等待 K 物理停止，无法停止时进入 L473 的执行域终止流程。

建议明确 activity lease / 当前所有权，而不是只用“由谁产生”的历史关系：

• wait只等待仍持有 P 或 B activity lease 的活动；
• isolate若允许计算继续，必须原子结束原 P / B activity，并把 continuation 重新归属 target 或 provider domain；continuation 自行持有所需资源，不得再访问 P / B，也不得依赖 P 即将释放的 dependency edge；
• provider 的共享 scheduler、heartbeat 等 domain 基础设施不归属于任一 Package，但不得在 lease 撤销后保存 Package / binding 指针；
• 若不希望引入所有权转移，则删除 isolate这个替代项，明确只有物理停止 / 取消完成后 wait才能成功。

同一处还可顺手把 L475 的“仍有有效引用的 binding”改成状态条件。ImportBinding 没有独立引用计数；建议只恢复 owning Package 仍为 Running且故障前为 active 的 binding，Stopping、never-active 或已关闭待 drain 的 binding 不得重新打开。

P2：澄清与编辑性问题

2. 宿主路径并不总能无损表示为当前声明路径字符串

允许绝对路径本身是已经明确接受的设计，本项不反对这一点。剩余缺口在于 root / dir 被定义为普通字符串，但安装目录又没有任何限制。

POSIX 上 /tmp/pkg\A 是合法目录名，其中反斜杠属于文件名本身。若 Package 安装于该目录，${root}必须表示 /tmp/pkg\A；但它经自定义变量传播到路径字段后，L76 又会把反斜杠解释为分隔符，实际访问 /tmp/pkg/A。当前字符串语法无法无损表达这个规范允许的 Package root。类似地，若 Loader 把相对来源 packages/foo直接作为 ${root}，官方 assets = ${root}/assets 示例还会在 desc 目录下重复定基。

建议二选一：

• 规定 ${root} / ${dir} 必须是 fully-qualified、lexically-normalized 且可由声明路径语法无损表示的字符串；来源路径不可表示时拒绝该来源；或
• 保留 native path / opaque handle，不把 Runtime 自己生成的 root / dir 重新降成会被 L76 tokenization 的普通路径字符串。

同时建议给出唯一流水线：变量展开 → 对最终字符串拒绝 NUL → 按本规范的 /与反斜杠规则识别路径种类 → 绝对路径直接使用或为相对路径加声明目录 → 词法规范化 → 宿主 I/O。Windows 的 fully-qualified、drive-relative（C:models/m）和 current-drive-rooted（\models\m）也应分别规定；后两者不能同时既“由宿主解释”又保证以声明目录为基准。

3. 多语言 map 下 name 的“为空则使用 id”没有唯一含义

多语言字段现在由 Runtime 原样保存完整 map，但 name仍写成“如为空则与 id 一致”：

"name": { "_": "", "zh-CN": "名称" }

这里可以解释为保留完整 map、只把 _替换为 id，或把整个字段视为空并替换为 {"_": id}。Runtime 已不再选择语言，因而不能通过某个“当前语言值”判断字段是否为空。

建议把缺省与显式空值拆开：字段缺失时生成 {"_": id}；显式空字符串是原样保留、逐 key 回退还是整份拒绝，再选择一种规则写明。纯字符串 ""也应遵守同一规则。

4. 已统一的 Package 示例仍有 capability 名称错位

Variance 模块示例声明实际 predictions为 breathiness、duration；同一 Package 的 Singer 示例却从该 :inference/variance请求 tension、energy。

具体 roles 与 predictions 的约束属于外部 interface 契约，因此这里不把它判为协议错误；但正文已经说明导入方应根据目标实际 exports填写 options，连续示例目前会让读者误以为四个名称可以任意错位。若 roles应选自 predictions，建议把 Variance 的导出改为 tension、energy；若二者并非这种关系，则在示例旁说明映射规则。

结论

本轮最优先的是第 1 项：新加入的 binding 级隔离目标是合理的，但需要明确“隔离后仍运行的计算”是否还算原 Package 的活动，否则 wait无法得到唯一后置条件。第 2～4 项均为 P2，不应阻塞整体设计；其中第 2 项只要求把新绝对路径方案的表示边界写完整，不重新讨论 Package 是否应受沙箱限制。

[SineStriker]

第七轮复审（d690be3）

本轮基线为 docs/ds-spec-2.4.md@d690be3，并已逐项核对第六轮处理说明。范围仍只限规范本身；refactor 是待重构的旧实现，未实现新版规范不计为风险。

先确认处理结果：第六轮的变量 anchor 问题已通过允许绝对资源路径改成另一套明确设计；abort 与 teardown 违约后的行为被明确设为未定义；动态变量名、示例 ID / 目录以及 ImportBinding / 调用级隔离要求也都已补入正文。本轮不重新争论这些产品取舍，只检查新文字能否彼此闭合。

P0：无新增阻塞项

没有发现新的 P0。本轮只有一处会使卸载与故障隔离产生不同架构实现的 P1；其余是低成本的路径表示、字段默认值和示例澄清。

P1：重要问题

1. isolate 与 wait 的“全部活动已停止”后置条件不一致

新增的 ImportBinding 隔离规则允许 provider 对某条 binding 的既有活动执行“停止、取消或隔离”，并把安全销毁门槛定义为这些活动不再访问 owning Package 或 binding；但 wait 的后置条件又要求“由该 Package 实例产生的所有执行活动均已停止”。

最小反例：

P 经 ImportBinding B 调用共享 target D，启动不可取消的远端 / GPU 计算 K
close(B)
provider 撤销 K 的 callback 与结果通道，并原子清除 K 对 P / B 的全部访问
K 继续只使用 D 自身状态运行

按 L434，K 已被成功隔离，P / B 可以在不破坏其他 binding 的情况下进入安全销毁；按 L467，K 历史上仍是“由 P 产生”的活动且尚未停止，P.wait()不能成功。于是实现会分成两类：

• isolate等同于逻辑完成 / 所有权转移，P 可以正常卸载；
• 必须等待 K 物理停止，无法停止时进入 L473 的执行域终止流程。

建议明确 activity lease / 当前所有权，而不是只用“由谁产生”的历史关系：

• wait只等待仍持有 P 或 B activity lease 的活动；
• isolate若允许计算继续，必须原子结束原 P / B activity，并把 continuation 重新归属 target 或 provider domain；continuation 自行持有所需资源，不得再访问 P / B，也不得依赖 P 即将释放的 dependency edge；
• provider 的共享 scheduler、heartbeat 等 domain 基础设施不归属于任一 Package，但不得在 lease 撤销后保存 Package / binding 指针；
• 若不希望引入所有权转移，则删除 isolate这个替代项，明确只有物理停止 / 取消完成后 wait才能成功。

同一处还可顺手把 L475 的“仍有有效引用的 binding”改成状态条件。ImportBinding 没有独立引用计数；建议只恢复 owning Package 仍为 Running且故障前为 active 的 binding，Stopping、never-active 或已关闭待 drain 的 binding 不得重新打开。

• **处理方式：**明确 isolate 是活动归属的原子转移。仍继续运行的 continuation 必须重新归属于 target 或 provider 执行域，独立持有所需资源，并且不得再访问原 Package、binding 或即将释放的 dependency edge；完成转移后不再属于原 Package 的 wait 集合。wait 只等待当前仍归属于 Package 或其 binding 的活动。恢复条件改为 owning Package 仍为Running且故障前为 active 的 binding，Stopping、never-active 或已关闭待 drain 的 binding 不得重新打开。

P2：澄清与编辑性问题

2. 宿主路径并不总能无损表示为当前声明路径字符串

允许绝对路径本身是已经明确接受的设计，本项不反对这一点。剩余缺口在于 root / dir 被定义为普通字符串，但安装目录又没有任何限制。

POSIX 上 /tmp/pkg\A 是合法目录名，其中反斜杠属于文件名本身。若 Package 安装于该目录，${root}必须表示 /tmp/pkg\A；但它经自定义变量传播到路径字段后，L76 又会把反斜杠解释为分隔符，实际访问 /tmp/pkg/A。当前字符串语法无法无损表达这个规范允许的 Package root。类似地，若 Loader 把相对来源 packages/foo直接作为 ${root}，官方 assets = ${root}/assets 示例还会在 desc 目录下重复定基。

建议二选一：

• 规定 ${root} / ${dir} 必须是 fully-qualified、lexically-normalized 且可由声明路径语法无损表示的字符串；来源路径不可表示时拒绝该来源；或
• 保留 native path / opaque handle，不把 Runtime 自己生成的 root / dir 重新降成会被 L76 tokenization 的普通路径字符串。

同时建议给出唯一流水线：变量展开 → 对最终字符串拒绝 NUL → 按本规范的 /与反斜杠规则识别路径种类 → 绝对路径直接使用或为相对路径加声明目录 → 词法规范化 → 宿主 I/O。Windows 的 fully-qualified、drive-relative（C:models/m）和 current-drive-rooted（\models\m）也应分别规定；后两者不能同时既“由宿主解释”又保证以声明目录为基准。

• **处理方式：**只补充 Runtime 生成值的可表示性边界，不规定各宿主路径种类的完整流水线。${root}与${dir}必须是 fully-qualified、词法规范化且能由本规范路径字符串无损表示的路径；Package root 或声明目录无法满足要求时拒绝该 Package 来源。盘符、UNC、drive-relative 等其余解释继续由宿主路径实现负责。

3. 多语言 map 下 name 的“为空则使用 id”没有唯一含义

多语言字段现在由 Runtime 原样保存完整 map，但 name仍写成“如为空则与 id 一致”：

"name": { "_": "", "zh-CN": "名称" }

这里可以解释为保留完整 map、只把 _替换为 id，或把整个字段视为空并替换为 {"_": id}。Runtime 已不再选择语言，因而不能通过某个“当前语言值”判断字段是否为空。

建议把缺省与显式空值拆开：字段缺失时生成 {"_": id}；显式空字符串是原样保留、逐 key 回退还是整份拒绝，再选择一种规则写明。纯字符串 ""也应遵守同一规则。

• **处理方式：**拆分字段缺失与显式空值。name缺失时等价于{"_": id}；字段显式存在时完整原样保存，包括空字符串或 value 为空的 map，Runtime 不按语言项执行回退。"name": ""等价于"name": {"_": ""}，不会替换为模块 ID。

4. 已统一的 Package 示例仍有 capability 名称错位

Variance 模块示例声明实际 predictions为 breathiness、duration；同一 Package 的 Singer 示例却从该 :inference/variance请求 tension、energy。

具体 roles 与 predictions 的约束属于外部 interface 契约，因此这里不把它判为协议错误；但正文已经说明导入方应根据目标实际 exports填写 options，连续示例目前会让读者误以为四个名称可以任意错位。若 roles应选自 predictions，建议把 Variance 的导出改为 tension、energy；若二者并非这种关系，则在示例旁说明映射规则。

• **处理方式：**将 Variance 示例的exports.predictions改为tension与energy，与同一 Package 的 Singer 示例中:inference/variance对应的options.roles保持一致。

结论

本轮最优先的是第 1 项：新加入的 binding 级隔离目标是合理的，但需要明确“隔离后仍运行的计算”是否还算原 Package 的活动，否则 wait无法得到唯一后置条件。第 2～4 项均为 P2，不应阻塞整体设计；其中第 2 项只要求把新绝对路径方案的表示边界写完整，不重新讨论 Package 是否应受沙箱限制。

[yqzhishen]

第八轮复审（b8412aa）

本轮基线为 docs/ds-spec-2.4.md@b8412aa，并已逐项核对第七轮处理说明。范围仍只限规范自身；refactor 是待重构的旧实现，未实现新版规范不计为风险。

先确认处置结果：第七轮的 isolate / wait 原始分叉、已安装目录的 ${root} / ${dir} 可表示性、name 空值规则和示例 capability 名称都已按回复落入正文。其中后两项已经闭合；前两项的原反例也已消除，但新规则与 raw DSPK source、Runtime 最终销毁分别留下一个后续生命周期缺口。

P0：无新增阻塞项

没有发现新的 P0。下面两个 P1 都需要在冻结前给出唯一责任边界，但不要求推翻当前 Package、绝对路径或 provider 隔离方案。

P1：重要问题

1. raw DSPK source 没有稳定、可用于 ${root} / ${dir} 的物化根

规范一方面把 Package 的最小分发单元定义为单个 DSPK ZIP，并在依赖候选条件中明确写出 “DSPK 或安装目录”；另一方面，新规则要求 ${root} / ${dir} 必须是可交给宿主文件系统的 fully-qualified 普通路径。ZIP 内的 desc.json 与模块声明目录本身没有这种宿主目录路径。

最小场景：搜索路径中只有 foo.dspk，其中写有：

{
  "description": "${root}",
  "readme": "${root}/assets/readme.txt"
}

Loader 若支持 raw DSPK，只能在 noLoad 前后采用某种解压、挂载或虚拟化：

• 临时解压到 T1 可以产生合法 root，但 load 允许重新读取而不复用快照；若再次物化到 T2，${root} 可以进入任意 JSON 字符串，故两次输入不再等价。
• 保留 T1 则需要定义这个物化根从 noLoad、Acquire、rollback 到 Package 卸载的 lease 与清理时机；当前没有这类 source 生命周期。
• 在 noLoad 中隐式持久安装会改变文件系统状态，又与 “noLoad 无副作用”的现有模型冲突，且安装目的地没有输入。
• 直接拒绝 raw DSPK 虽能保持内部一致，却会使“DSPK 也是 candidate source”失去规范性含义。

建议三选一，并明确写成 source invariant：

1. Loader 只接受已安装目录；raw DSPK 必须先由 Installer 显式安装，再进入候选集合。
2. 定义 load-scoped materialization：在 noLoad 前按安全解包规则只物化一次，得到不可变的 fully-qualified root；noLoad、load及实例存活期必须复用同一 root，失败或最后引用释放后再清理。
3. 定义 archive-native 的虚拟路径 / resource abstraction，不再要求 raw DSPK 中的 root 伪装成宿主普通目录。

2. provider execution domain 成为 activity owner 后，没有 Runtime 销毁时的静止屏障

新隔离规则允许仍运行的 continuation 原子脱离原 Package / ImportBinding，改归 provider execution domain；Package wait此后明确不再等待它。这解决了上一轮的 Package wait-set 分叉，但规范只为 Package 定义 quit / wait / 强制终止，最终 plugin 卸载只有对象销毁顺序，没有 provider-domain activity 的 close / drain 后置条件。

最小场景：

P 经 binding B 启动长时计算 K
close(B) 将 K 合法转交给进程内 provider domain E
K 只访问 E 独立持有的 buffer，不再访问 P、B 或 dependency
P.wait 成功，P 正常卸载
随后销毁 Runtime，此时 K 仍在执行 plugin 代码

这里 provider 没有违反现文：isolate 明确允许 K 继续，且 Package wait 已合法成功。因此 Package wait 失败才触发的执行域终止规则不会运行。此时直接销毁 K 的资源可能造成悬空访问，卸载 plugin 会让线程继续执行已卸载代码；无限等待 K 又没有对应的 Runtime shutdown 契约。

建议把 provider execution domain 定义为一等的 Runtime-owned lifecycle owner：

• continuation 转入前先在新 domain 注册其 activity 与资源所有权，完成后注销；
• Runtime shutdown 原子关闭 domain ingress，停止 / 取消并 drain 全部 domain-owned continuation、scheduler 与 heartbeat；
• barrier 失败时终止并确认最小执行域；同进程无法证明静止时沿用 fail-fast；
• 只有 domain 已静止后，才能销毁 plugin 创建的对象并卸载 plugin；
• 不能提供这套协议的 domain 不得接收隔离 continuation，只能把它转交给具体 target Package 或物理停止。

同时应把 L436 的 owner 不变量改成“Package（经 binding 产生时还属于该 binding）或已注册的 provider domain”；否则“每项运行时活动都属于具体 Package”与下一段允许 provider-domain ownership 字面相冲突。

P2：低成本澄清

3. 多语言路径交给前端时，返回的是原相对串还是已解析路径

多语言 map 规则要求 Runtime API 返回原 key 和“完成变量展开后的 value”；路径规则又要求每个本地化路径 value 按声明文件目录分别解析。

例如 /pkg/singer/singer.json 中的：

"avatar": { "_": "../assets/a.png" }

API 返回 ../assets/a.png最贴近“展开后的 value”，但前端若只取得 map 就没有声明目录；返回 /pkg/assets/a.png则已经执行了路径解析。建议明确区分 MultilingualText 与 MultilingualPath：前者返回展开后的字符串，后者返回完成基路径解析与规范化的 path value / resource handle；或者让后者同时携带 base / resolver context。具体宿主 path 类型可以留给 Runtime API 规范。

4. 两个贡献 ID 指向同一声明路径时，module instance 基数未定义

贡献条目只禁止同类别重复 id，没有规定规范化后重复的 path：

"inference": [
  { "id": "a", "path": "./m/../x/inference.json" },
  { "id": "b", "path": "./x/inference.json" }
]

实现可以为 a、b创建两个独立 module instance，也可以把它们视为同一实例的两个别名，或者直接拒绝。对有状态 provider，这会改变状态共享、初始化次数和卸载行为。建议明确 contribution entry 才是 module instance 的基数：不同 (Package, category, id)始终产生独立实例，声明路径相同也不自动合并；如果不希望支持这种复用，则直接要求同类别中完成变量展开与路径规范化后的声明路径唯一。显式 alias 若将来需要，应另设语法，而不应由路径碰巧相同推导。

结论

本轮最优先的是第 2 项：上一轮引入的 ownership transfer 已把 Package 卸载闭合，但也产生了一个不再属于任何 Package wait 集合的新 owner，因此必须补上 Runtime 级最终屏障。第 1 项则决定 raw DSPK 到底是 Loader 输入、Installer 输入还是需要稳定虚拟挂载，属于应在实现前选定的 source 模型。第 3～4 项均为 P2，不阻塞总体架构。

[SineStriker]

第八轮复审（b8412aa）

本轮基线为 docs/ds-spec-2.4.md@b8412aa，并已逐项核对第七轮处理说明。范围仍只限规范自身；refactor 是待重构的旧实现，未实现新版规范不计为风险。

先确认处置结果：第七轮的 isolate / wait 原始分叉、已安装目录的 ${root} / ${dir} 可表示性、name 空值规则和示例 capability 名称都已按回复落入正文。其中后两项已经闭合；前两项的原反例也已消除，但新规则与 raw DSPK source、Runtime 最终销毁分别留下一个后续生命周期缺口。

P0：无新增阻塞项

没有发现新的 P0。下面两个 P1 都需要在冻结前给出唯一责任边界，但不要求推翻当前 Package、绝对路径或 provider 隔离方案。

P1：重要问题

1. raw DSPK source 没有稳定、可用于 ${root} / ${dir} 的物化根

规范一方面把 Package 的最小分发单元定义为单个 DSPK ZIP，并在依赖候选条件中明确写出 “DSPK 或安装目录”；另一方面，新规则要求 ${root} / ${dir} 必须是可交给宿主文件系统的 fully-qualified 普通路径。ZIP 内的 desc.json 与模块声明目录本身没有这种宿主目录路径。

最小场景：搜索路径中只有 foo.dspk，其中写有：

{
  "description": "${root}",
  "readme": "${root}/assets/readme.txt"
}

Loader 若支持 raw DSPK，只能在 noLoad 前后采用某种解压、挂载或虚拟化：

• 临时解压到 T1 可以产生合法 root，但 load 允许重新读取而不复用快照；若再次物化到 T2，${root} 可以进入任意 JSON 字符串，故两次输入不再等价。
• 保留 T1 则需要定义这个物化根从 noLoad、Acquire、rollback 到 Package 卸载的 lease 与清理时机；当前没有这类 source 生命周期。
• 在 noLoad 中隐式持久安装会改变文件系统状态，又与 “noLoad 无副作用”的现有模型冲突，且安装目的地没有输入。
• 直接拒绝 raw DSPK 虽能保持内部一致，却会使“DSPK 也是 candidate source”失去规范性含义。

建议三选一，并明确写成 source invariant：

1. Loader 只接受已安装目录；raw DSPK 必须先由 Installer 显式安装，再进入候选集合。
2. 定义 load-scoped materialization：在 noLoad 前按安全解包规则只物化一次，得到不可变的 fully-qualified root；noLoad、load及实例存活期必须复用同一 root，失败或最后引用释放后再清理。
3. 定义 archive-native 的虚拟路径 / resource abstraction，不再要求 raw DSPK 中的 root 伪装成宿主普通目录。

• **处理方式：**选择最简单的 source 模型。.dspk只作为 Installer 输入，必须先按安全解包规则安装到目录；Loader 只从已安装 Package 目录执行noLoad与load，raw DSPK 不进入依赖候选，也不定义临时物化、挂载、lease 或虚拟路径机制。

2. provider execution domain 成为 activity owner 后，没有 Runtime 销毁时的静止屏障

新隔离规则允许仍运行的 continuation 原子脱离原 Package / ImportBinding，改归 provider execution domain；Package wait此后明确不再等待它。这解决了上一轮的 Package wait-set 分叉，但规范只为 Package 定义 quit / wait / 强制终止，最终 plugin 卸载只有对象销毁顺序，没有 provider-domain activity 的 close / drain 后置条件。

最小场景：

P 经 binding B 启动长时计算 K
close(B) 将 K 合法转交给进程内 provider domain E
K 只访问 E 独立持有的 buffer，不再访问 P、B 或 dependency
P.wait 成功，P 正常卸载
随后销毁 Runtime，此时 K 仍在执行 plugin 代码

这里 provider 没有违反现文：isolate 明确允许 K 继续，且 Package wait 已合法成功。因此 Package wait 失败才触发的执行域终止规则不会运行。此时直接销毁 K 的资源可能造成悬空访问，卸载 plugin 会让线程继续执行已卸载代码；无限等待 K 又没有对应的 Runtime shutdown 契约。

建议把 provider execution domain 定义为一等的 Runtime-owned lifecycle owner：

• continuation 转入前先在新 domain 注册其 activity 与资源所有权，完成后注销；
• Runtime shutdown 原子关闭 domain ingress，停止 / 取消并 drain 全部 domain-owned continuation、scheduler 与 heartbeat；
• barrier 失败时终止并确认最小执行域；同进程无法证明静止时沿用 fail-fast；
• 只有 domain 已静止后，才能销毁 plugin 创建的对象并卸载 plugin；
• 不能提供这套协议的 domain 不得接收隔离 continuation，只能把它转交给具体 target Package 或物理停止。

同时应把 L436 的 owner 不变量改成“Package（经 binding 产生时还属于该 binding）或已注册的 provider domain”；否则“每项运行时活动都属于具体 Package”与下一段允许 provider-domain ownership 字面相冲突。

• **处理方式：**只规定 owner 不变量与 Runtime shutdown 的结果要求，不引入 activity registry 或 domain generation 细节。每项活动任一时刻恰好归属于一个 Package 或已注册 provider domain。Runtime 整体销毁前必须关闭 provider domain 入口，停止并等待全部 domain-owned continuation 与基础活动，确认静止后才能销毁 plugin 对象并卸载 plugin。provider 必须使停止完成；违反要求的 provider 不合法，后续行为未定义。

P2：低成本澄清

3. 多语言路径交给前端时，返回的是原相对串还是已解析路径

多语言 map 规则要求 Runtime API 返回原 key 和“完成变量展开后的 value”；路径规则又要求每个本地化路径 value 按声明文件目录分别解析。

例如 /pkg/singer/singer.json 中的：

"avatar": { "_": "../assets/a.png" }

API 返回 ../assets/a.png最贴近“展开后的 value”，但前端若只取得 map 就没有声明目录；返回 /pkg/assets/a.png则已经执行了路径解析。建议明确区分 MultilingualText 与 MultilingualPath：前者返回展开后的字符串，后者返回完成基路径解析与规范化的 path value / resource handle；或者让后者同时携带 base / resolver context。具体宿主 path 类型可以留给 Runtime API 规范。

• **处理方式：**明确区分返回结果。多语言文本 map 返回完成变量展开的字符串 value；多语言路径 map 返回完成变量展开、声明目录定基和词法规范化后的路径 value，不向前端暴露脱离 base context 的原相对串。具体宿主路径类型由 Runtime API 规定。

4. 两个贡献 ID 指向同一声明路径时，module instance 基数未定义

贡献条目只禁止同类别重复 id，没有规定规范化后重复的 path：

"inference": [
  { "id": "a", "path": "./m/../x/inference.json" },
  { "id": "b", "path": "./x/inference.json" }
]

实现可以为 a、b创建两个独立 module instance，也可以把它们视为同一实例的两个别名，或者直接拒绝。对有状态 provider，这会改变状态共享、初始化次数和卸载行为。建议明确 contribution entry 才是 module instance 的基数：不同 (Package, category, id)始终产生独立实例，声明路径相同也不自动合并；如果不希望支持这种复用，则直接要求同类别中完成变量展开与路径规范化后的声明路径唯一。显式 alias 若将来需要，应另设语法，而不应由路径碰巧相同推导。

• **处理方式：**规定 (Package, category, contribution ID) 唯一确定 contribution instance；模块类别中也唯一确定 module instance。不同 ID 即使规范化后指向同一声明文件，也创建独立实例，不按路径自动合并或推导别名。未来若需要 alias，另设显式语法。

结论

本轮最优先的是第 2 项：上一轮引入的 ownership transfer 已把 Package 卸载闭合，但也产生了一个不再属于任何 Package wait 集合的新 owner，因此必须补上 Runtime 级最终屏障。第 1 项则决定 raw DSPK 到底是 Loader 输入、Installer 输入还是需要稳定虚拟挂载，属于应在实现前选定的 source 模型。第 3～4 项均为 P2，不阻塞总体架构。