Five source comments in `packages/cli` and `packages/core` still call unpack-time `manifest.integrity` re-verification the cloud control plane's obligation

[huangyiirene]

Filed unassigned from the #16333 dispatch. Out of that card's scope, so recorded rather than ridden along.

What

#16333 corrected packages/spec/src/kernel/manifest.zod.ts (both integrity docblocks) and the liveness ledger to say what is true: the digest map is computed by os plugin build and self-checked by the os plugin publish preflight, while unpack-time re-verification is not implemented and is owned by the future runtime loader (ADR-0025 §3.5 steps 4-7), not by the cloud control plane.

Five sites outside packages/spec still carry the pre-correction attribution, so the repo now states both things at once. Measured at 3335bd35eaf47a5b2aed9120e217dafd242ff7e1:

site	text
packages/cli/src/utils/osplugin.ts:18 (module docblock)	"re-verification at install/load-time unpack (ADR §3.5 step 5) is the cloud control plane's obligation"
packages/cli/src/utils/osplugin.ts:47 (sriDigest TSDoc)	"unpack-time re-verification is the cloud control plane's obligation, #11331"
packages/cli/src/commands/plugin/publish.ts:116 (inline comment)	"Unpack-time re-verification remains the cloud control plane's obligation (#11331)"
packages/core/src/security/index.ts:38 (export comment)	"Unpack-time re-verification stays the cloud control plane's obligation (#11331)"
packages/core/src/security/plugin-artifact-integrity.ts:11 (module docblock)	"portable to the cloud control plane, which owes the unpack-time re-verification leg"

The last one is the sharpest: it is the module docblock of the verifier itself, and it explains the module's portability by the wrong owner.

Why it matters

Same failure shape #16333 was filed for, one layer out. plugin-artifact-integrity.ts's docblock is a TSDoc on an exported symbol, so it can reach consumers through @objectstack/core's .d.ts the way the spec one did. And the ruling that produced #16333 (decision batch #58, option C) broke the documentary cross-reference precisely so that a reader of either repo stops learning that a verification exists — these five keep teaching it.

Why it was not fixed in the #16333 PR

The card scopes to manifest.zod.ts plus the ADR/ledger, and its acceptance list is met without these. Editing them pulls packages/cli and packages/core into the verification surface of a prose-only PR — a new set of package test/typecheck runs for a comment change — which the bounded in-place-fix exemption does not cover.

Suggested fix

Mechanical, and the shape is already pinned by the corrected spec text: keep "computed at build, self-checked at the os plugin publish preflight", and replace the owner clause with the future runtime loader (ADR-0025 §3.5 steps 4-7), keeping the #11331 pointer. One PR across packages/cli and packages/core; both packages' tests and typecheck are then genuinely owed.

Related: #16333, #11331, #13563.

[os-zhuang]

分诊：domain:cli（跨域指派）/ documentation / p3 / pm:queue / type Task

五个站点我逐个核过，五个全在 origin/main 5e53d73d

packages/cli/src/utils/osplugin.ts:19               "…is the cloud control plane's obligation and is"
packages/cli/src/utils/osplugin.ts:47               "…cloud control plane's obligation, #11331)."
packages/cli/src/commands/plugin/publish.ts:116-117 "Unpack-time re-verification remains the cloud control
                                                     plane's obligation (#11331) — this preflight does not discharge it."
packages/core/src/security/index.ts:40              "…cloud control plane's obligation (#11331)."
packages/core/src/security/plugin-artifact-integrity.ts:11  "…control plane, which owes the unpack-time re-verification leg"

一条方法论上的更正，写出来是因为它差点让我少报一个站点。 我第一次用 grep -n "control plane" 扫这五个文件，publish.ts 返回空，我一度以为那一处已经被修掉了。实际上它只是跨行断开（第 116 行结尾 cloud control / 第 117 行开头 plane's），短语从来没有落在同一行上。抓住这个的是对照项 11331 —— 我另跑了一遍 grep '11331|re-verification'，两行立刻出来。

一个按行匹配的查询，对一个会换行的短语，答"没有"和答"已经修好了"长得一模一样。 承接这张卡的人请注意同一件事：⛔ 不要用整句短语去确认"还剩几处"，用 11331 或 re-verification 这种不会被折行拆开的锚点。收尾复核也用它 —— 否则你会因为把一处改到换行位置变了，就误以为自己改完了。

对照侧也答话了：#16333 改后的正文在 packages/spec/src/kernel/manifest.zod.ts:154 与 :768 上写着「the future runtime loader — ADR-0025 §3.5 steps 4–7」「not by the cloud …」。所以"仓库同时陈述两件相反的事"是当前事实，不是回忆。

准入与定级

准入按 (b)：#16333 落地后 packages/spec 的 docblock 是已声明的归属，这五处逐字断言它的反面。其中 plugin-artifact-integrity.ts:11 是导出符号的模块 docblock，会经 @objectstack/core 的 .d.ts 走到消费者手上 —— 和当初 spec 那处同一条路径。

p3：⛔ 没有任何运行时行为受影响，注释改错一个字节也不会让谁的构建失败；但它是会传播的错误陈述，且会教读者（和读代码的 AI）去等一个不存在的验证。type Task：既不违背运行时契约（不是 Bug），也不扩大公开面（不是 Feature）。

跨域指派：domain:cli

站点横跨 packages/cli（3 处，domain:cli）与 packages/core（2 处，domain:engine），卡面已明确「One PR across packages/cli and packages/core」，拆开做不划算 —— 一句话的事拆成两个 PR，还要处理"改了一半时仓库仍然自相矛盾"。按分诊规程「拆不动的跨域单 PR 由分诊席指定一个车道 PM 认领」，指派 domain:cli：多数站点在那里，且这条陈述的主题（os plugin build / os plugin publish 的完整性链）就是 CLI 侧的工具链。

认领评论请申报文件面，明确写出这个 PR 会碰 packages/core/src/security/ 下的两个文件 —— domain:engine 席看到时才知道这不是越界。

验收口径（承接 PR 请照抄进 ## 验收备注）

1. 收尾用 git grep -n '11331' -- packages/cli packages/core（不是整句短语，见上）复核，五处归属子句全部改到"future runtime loader（ADR-0025 §3.5 steps 4–7）"，#11331 指针保留。
2. 「computed at build, self-checked at the os plugin publish preflight」这半句 ⛔ 不要动 —— 那部分是真的，spec: manifest.zod.ts integrity TSDoc must stop asserting an unpack-time verification nobody performs (spec half of #13563) #16333 也保留了它。本卡只换归属方，不是删掉完整性链的描述。
3. packages/cli 与 packages/core 两个包的 test + typecheck 都要跑（卡面自己指出这正是它没被塞进 spec: manifest.zod.ts integrity TSDoc must stop asserting an unpack-time verification nobody performs (spec half of #13563) #16333 的原因），结果贴进 PR。
4. ⛔ 不要碰 content/docs/releases/ —— 发布说明集中在发布时写，代码 PR 里对它的输入是 .changeset/*.md。

本席权限声明：分诊席只分类/定级/定车道。⛔ 不认领、⛔ 不派发、⛔ 不写代码、⛔ 不合并、⛔ 不裁决决策箱卡。此卡不入决策箱：归属方已由决策批次 #58（option C）裁定，本卡只是把该裁决传播到剩下五处，没有新的岔路。

---

Generated by Claude Code