Request CI provenance for @deepseek-ai/dsh-sdk-jsonrpc-demo@0.1.0-rc.8

[d66431536-byte]

根据社区建议，现将可以自行核对的事实、发布来源诉求和接口兼容性诉求分开说明（2026-10-08 更新原帖）。

1. 当前可独立核对的事实

目标包为 @deepseek-ai/dsh-sdk-jsonrpc-demo。以下是 2026-10-08 14:48 UTC 对 npm 全版本元数据、各版本 npm attestation API 及官方 tag refs的查询结果；表中包名均属 @deepseek-ai scope。

包名	npm 版本	当前 npm CI provenance	当前同版本官方 tag	tag 指向的 commit
dsh-sdk-jsonrpc-demo	0.0.1-rc.5	dist.attestations 缺失；API 404	dsh-v0.0.1-rc.5 未列出	未确定
dsh-sdk-jsonrpc-demo	0.1.0-rc.2	dist.attestations 缺失；API 404	dsh-v0.1.0-rc.2 未列出	未确定
dsh-sdk-jsonrpc-demo	0.1.0-rc.3	dist.attestations 缺失；API 404	dsh-v0.1.0-rc.3 未列出	未确定
dsh-sdk-jsonrpc-demo	0.1.0-rc.6	dist.attestations 缺失；API 404	dsh-v0.1.0-rc.6 未列出	未确定
dsh-sdk-jsonrpc-demo	0.1.0-rc.7	dist.attestations 缺失；API 404	dsh-v0.1.0-rc.7	99f6f02fec
dsh-sdk-jsonrpc-demo	0.1.0-rc.8	dist.attestations 缺失；API 404	dsh-v0.1.0-rc.8	141eb6fef8
dsh-sdk-jsonrpc-demo	0.1.1-rc.1	dist.attestations 缺失；API 404	dsh-v0.1.1-rc.1	528c682e06
dsh-sdk-jsonrpc-demo	0.1.1-rc.2	dist.attestations 缺失；API 404	dsh-v0.1.1-rc.2	b150a551b8

8 个版本均有 dist.signatures、均未提供 gitHead。表格只说明当前公开 npm 入口未提供 CI provenance，不能推出所有外部渠道从未生成证明。tag → commit 可以自行核对，但它不证明 npm tarball 由该 commit 或某个 CI 构建。

本项目已核对 rc.8 下载产物摘要、安装闭包及关键入口/协议实现。第三方还可以依据固定源码和构建环境复现、逐文件比较产物；源码行号相近或内容相符属于交叉核对，不能替代 CI 签名证明。已成功验签的 rc.8 GitHub Release attestation仅绑定源码 tag/commit，未绑定以下 npm tarball。

本帖请求的目标产物：

• Package: @deepseek-ai/dsh-sdk-jsonrpc-demo@0.1.0-rc.8
• Artifact: npm rc.8 tarball
• SHA-256: 81152447823fd86a8e5537f368bb0144ea028535a14169a2c409d5cf4a49cbd6
• SHA-512: e98fae28ce176445e16237d57e42aad89cf0a2916d8613ae681f00025b0a9829a8306a105f25c01d7e77bf45beeb7e48aca88377ae2d11e22c7d467cb6165a86
• 可核对源码 ref: refs/tags/dsh-v0.1.0-rc.8；commit: 141eb6fef83422698aef7a981029e843e8161534。真实构建/发布 workflow 身份仍请发布方确认。

2. 请发布方处理的最小来源诉求

请在后续官方 npm 发布中启用 npm provenance；若暂时不能启用，请公开或指明真实发布仓库中的签名 workflow、构建脚本和固定构建输入，使第三方能够复现并比对实际发布内容。 公开镜像里已有的 workflow 是否就是实际发布流程，也请明确。

如果 rc.8 的原 CI bundle 已保留，提供绑定上述 tarball 摘要的可下载原件即可；我们将独立核验签名、真实 signer/workflow、源码 ref/commit 和 SLSA build provenance。启用未来发布的 provenance 不会自动补齐旧 rc.8 的历史证明；公开脚本或第三方复现也不替代本项目要求的官方 CI 签名证明。无需提供任何 API Key、发布 token 或私有凭据。

3. 独立的接口兼容性问题

本项目当前已完成本地兼容性复验的固定版本是 0.1.0-rc.8。入口为 lib/packaged-bin.js，以 node <入口> <cordis.yml> 启动，从已安装消费方闭包解析 bare plugins；协议为 UTF-8、逐行 JSON 的 stdio JSON-RPC 2.0，stdout 仅输出协议帧。所需合同如下：

• initialize({cwd, provider, model, maxTokens})（maxTokens 可选）：握手返回 serverInfo.name=deepseek-harness-sdk-runtime、version=0.0.1（握手版本与 npm 包版本不同）。
• session/prompt({sessionId, contentBlocks:[{type:'text',text}]})：返回非空 messageId。
• 按 sessionId 消费 session.event：agent/inbox/spliced receipt 的 data.inserted[].id 关联返回的 messageId，读取 assistant/message 文本及 turn/end 中 reason.kind=error 的错误；session.status 为 running/idle，并保留 subagent.started/finished 通知。
• shutdown({}) 及 stdin EOF / SIGTERM 后清理退出。

同版本依赖为 dsh-sdk-jsonrpc-server、dsh-llm-deepseek、dsh-agent-spine-demo、dsh-session-persistence-jsonl。rc.8 的本地协议、安装闭包和合成 Provider 场景已复验，官方真实模型调用尚未执行；0.1.1-rc.1 / 0.1.1-rc.2 尚未完成本项目兼容性复验，因此不将 rc.8 称为“上游最后可用版本”。

请维护者确认上述 packaged stdio 入口目前受支持的官方发布版本，或提供对应的新入口及迁移说明。 该问题与来源证明分别处理、分别复验，不要求通过同一次版本发布解决。

[PerryLink]

这类请求先分清"今天就能验的"与"需要发布方配合的"

1. 今天就能独立验证的部分（不需要发布方配合）

• 标签 ↔ 提交的对应：仓库里有 tag（例如 dsh-v0.2.1-alpha.1 → commit 5badb15009）⇒ 任何人都能 git tag --contains / 直接看 tag 指向的提交，无需信任发布流程；
• 包内容可比对：npm pack 解出的产物可与该提交构建比对（社区里已有人用"产物行号 vs 源码行号偏移一致"这种方式做交叉验证）；
• 是否带 provenance：npm view <pkg> dist.attestations（或 registry 页面的 provenance 标记）能直接看出该版本是否用 --provenance 发布——这是一个可枚举的事实，比争论"应不应该"有效。

建议你先把这三样做成一张表（包名 / 版本 / 有无 attestation / tag / commit）⇒ 这张表本身就是最有说服力的诉求材料。

2. 需要发布方配合的部分（就是你提的那些）

你要求的 CI bundle、可独立验签的签名、签名工作流、对应 tag 与 source commit —— 这些只能由发布方提供。⇒ 建议把诉求压成一条最小可执行项：

在发布流程中启用 npm provenance（--provenance），使每个已发布版本带有可验证的构建来源；若暂不启用，请公开签名工作流与构建脚本，使第三方可复现构建。

"二选一"比一次性列四五项更容易被回应：provenance 是一条命令级改动，公开构建脚本是零改动（仓库里本来就有构建配置）。

3. 一处措辞建议

你写"如 rc.8 从未生成此证明，请提供保留该接口的兼容官方发布版本"。⇒ 这一句把两件事混在了一起（来源证明 与 接口兼容/版本选择）。它们应由不同的人处理、修法也不同。⇒ 建议拆成两段：一段只谈 provenance/可验证性，一段谈你需要的接口在哪个版本可用。

4. 请补两样

1. 那张对照表的现状（哪些版本已有 attestation）⇒ 有了它，"从未生成"就从断言变成结论；
2. 你需要的接口名与最后可用的版本（这样"兼容版本"那条才能被具体回应，而不是靠猜）。

5. 一条边界

我确认的是**"标签↔提交可自行验证"与"dist.attestations 可枚举"这两种独立验证手段存在**。该包的发布流程是否已启用 provenance 我没有查（那需要按包名查询 registry）——这正是第 1 节请你先做成表的原因。

[d66431536-byte]

感谢建议。我们已补齐公开版本事实，并将来源证明和接口兼容性分开说明。

目标包统一为 @deepseek-ai/dsh-sdk-jsonrpc-demo。2026-10-05 查询 npm registry 元数据 的全部 8 个版本，并核对官方当前 tag 列表：

npm 版本	dist.attestations	当前官方同版本 tag	tag 指向的 commit
0.0.1-rc.5	缺失	未找到	未确认
0.1.0-rc.2	缺失	未找到	未确认
0.1.0-rc.3	缺失	未找到	未确认
0.1.0-rc.6	缺失	未找到	未确认
0.1.0-rc.7	缺失	dsh-v0.1.0-rc.7	99f6f02fecdb7dff40c3fbc9470f5907c29f74ca
0.1.0-rc.8	缺失	dsh-v0.1.0-rc.8	141eb6fef83422698aef7a981029e843e8161534
0.1.1-rc.1	缺失	dsh-v0.1.1-rc.1	528c682e061696f5a160f363f236ecbf53cbd006
0.1.1-rc.2	缺失	dsh-v0.1.1-rc.2	b150a551b8d465e31e418e1b2eaf5e79bbb7d28e

这些 npm 版本均缺少 gitHead，均有 registry signature。四个已找到的 tag 下，packages/examples/jsonrpc-demo/package.json 的包名和版本与表中相符；这只确认源码版本对应关系，不证明 tarball 的 CI 构建来源。dist.attestations 缺失指 registry 当前未公开此字段，不能推出所有外部渠道从未生成证明。我们也已取得并成功验签 rc.8 的 GitHub Release attestation，但它绑定源码 tag/commit，不含 npm tarball 摘要，不满足 CI 产物证明要求。

来源证明诉求：请官方发布者提供绑定本帖目标 tarball 的可独立验签 SLSA CI provenance；若现有版本没有该材料，请为后续发布启用 npm provenance（--provenance），或提供绑定本次构建、实际发布 tarball 的签名 bundle。官方构建脚本已公开，本地复现和内容比对也已完成；这些是补充证据，当前项目仍要求签名 CI provenance。

接口兼容性诉求独立如下：当前已完成本地协议复验的版本为 0.1.0-rc.8，消费入口为 lib/packaged-bin.js，以 node <入口> <cordis.yml> 启动并从已安装消费方闭包解析 bare plugins。需要 UTF-8、一行一个 JSON 的 stdio JSON-RPC 2.0，stdout 仅输出协议帧：

• initialize({cwd, provider, model, maxTokens}) 返回 serverInfo.name=deepseek-harness-sdk-runtime、version=0.0.1。
• session/prompt({sessionId, contentBlocks:[{type:'text',text}]}) 返回非空 messageId。
• 通知 session.event 包含 agent/inbox/spliced receipt 和 assistant/message 文本；session.status 支持 running / idle；保留 subagent.started / subagent.finished 通知。
• shutdown({})，以及 stdin EOF / SIGTERM 后清理退出。

依赖同版本的 dsh-sdk-jsonrpc-server、dsh-llm-deepseek、dsh-agent-spine-demo、dsh-session-persistence-jsonl。rc.8 的本地协议、安装闭包和合成 Provider 场景已复验，官方真实模型调用尚未执行；0.1.1-rc.1 / rc.2 尚未完成本项目兼容性复验，因此不把 rc.8 称为“上游最后可用版本”。请维护者明确上述 packaged stdio 入口后续在哪个发布版本可用；取得带证明的候选版本后，我们会独立复验兼容性。

[d66431536-byte]

根据社区建议，已于 2026-10-08 直接整理本讨论主帖，补入全部 8 个 npm 版本的 provenance/tag/commit 对照表和项目实际依赖的接口合同，并将本条既有补充评论改为简明说明。

来源诉求： 请后续官方 npm 发布启用 provenance；暂时不能启用时，请公开或指明真实发布仓库的签名 workflow、构建脚本和固定输入，便于第三方复现比对。若 rc.8 原 CI 已保存绑定目标 tarball 的 bundle，直接提供下载链接即可。脚本、内容比对及源码 Release attestation 属于补充证据，不能替代目标 npm tarball 的官方 CI build provenance。

兼容性问题： 请确认 packaged-bin stdio JSON-RPC 入口的受支持官方版本，或提供新入口和迁移说明；确切方法及通知已列在主帖。本项目当前完成本地复验的是 0.1.0-rc.8，不据此认定它是上游最后可用版本。接口兼容性与来源证明分别处理、分别验证。

保留一项与真实发布流程有关的依据：rc.8 官方 npm 发布说明记录 package repository 与发布 workflow 所属组织不同；npm provenance 要求规定公开 repository 信息与实际发布来源匹配。因此先请发布方确认实际 publisher/workflow，具体配置由维护者按真实链路选择；此前 YAML 片段不再作为本帖要求。

当前查询未取得目标证明不等于证明从未生成；未来版本启用 provenance 也不会自动补齐旧版本的历史证明。无需提供 Key、token 或其他私有凭据。