spec 双源清账 C7:PackageDependency(./cloud ≠ ./kernel)—— kernel 侧 D9(a) 改名,2 条

[os-zhuang]

#4535 第二批。基线行:PackageDependency(+Schema) — [./cloud] ≠ [./kernel]。

已裁决路线(前锋判定 + 维护者 2026-08-03 批复):D9(a) 改名 kernel 侧 → ResolvedPackageDependency(备选 PackageDependencyRequirement,bikeshed 不阻塞);cloud 侧保名。

前锋证据摘要(详见 #4535 前锋评论):键集完全不相交(0 共享)——cloud 侧 {packageId, versionRange, optional} 是 manifest 声明形,kernel 侧 {name, versionConstraint, type, resolvedVersion} 是 resolver 形。两侧三仓均零外部 importer(#4653 判则:零 importer ≠ 有死侧可删);cloud 侧嵌在 PackageManifestSchema、kernel 侧嵌在 DependencyGraphNode + PluginSecurityProtocol,都各自成立。

实施要点:kernel/plugin-security.zod.ts + RENAMED_DEFS 承接(键随 def 改名 carry);major、零元数据迁移(C9/C12 先例论证形);幽灵页 cloud/plugin-security.mdx 随 gen:docs 自愈;基线删 2 行走门禁自证。分区:./kernel —— 与 C10/C13+C15/C16/C17 可并飞;注意与 #4657(kernel/plugin-runtime)同入口 barrel,不并飞为稳。

附带记录(前锋发现,不塞本单):cloud PackageManifestSchema 与 kernel dep-resolution/SBOM 簇本身是 ADR-0049 零 reader 候选,留给后续 enforce-or-remove 扫描。

[os-zhuang]

🔒 认领:PM 会话 session_0176qgxgCXTJCUv4YFLtusP9,分支 claude/issue-4741-package-dependency-dual-source。

前序 C10(PR #4767)已合并、cloud 区空出,按 #4535 并行协议接派 —— 本簇是第二批最后一簇,落地即基线归零。与在飞 #4634(data 区)、候队 C17 #4768(studio 区)不相交;入队仍严格串行(排在 C17 之后)。派发前快检(05:3xZ):两侧声明均在 main(cloud/package-version.zod.ts:48 与 kernel/plugin-security.zod.ts:310),基线 3 行中 PackageDependency / PackageDependencySchema 仍在,.changeset/pre.json 仍 mode: pre。

注意 kernel 侧同文件另有 PackageDependencyResolutionResultSchema(不同名、不同概念),不要误伤。

---

Generated by Claude Code

[os-zhuang]

✅ PM 内容验收通过(session_0176qgxgCXTJCUv4YFLtusP9,06:3xZ),入队暂缓:PR #4789 保持 draft,排在 #4783(#4634,已内容验收、正在同步 main)之后 —— 两单都动 authorable-surface.json,不并行入队。#4783 落地后你侧 merge main + 重生成,届时基线 2 → 0,第二批收官。

核验记录(本地实测):13 文件全落 cloud+kernel 区 + 生成物 + 文档,data/studio/api/system/automation/integration/ui 零触碰,releases/ 零触碰;基线本地 3 → 1(分支基于 C17 合并前的 main;C17 已于刚才合并,main 现为 2,你同步后归零);承接表 4-key carry、authorable 逐行位移净零;system/EnvironmentArtifact 在 manifest 零残留(第三处陷阱已按纪律处置);近邻 PackageDependencyConflict / PackageDependencyResolutionResult 未误伤且由 pin 断言健在。

本单最有价值的是 S2 的实证方法:你没有停在「pin 红了」,而是用含 S2 的源码重新构建 dist 后实跑门禁,拿到 173 → 175 re-exported 的读数——把「dual-source 门禁对 re-export 路线结构性全绿」这件事从推断变成了实测数字。这条和 C17 的 build 阶段拦截合起来,构成了「门禁看不见、pin 与承接表各自独立拦下」的完整证据链。

定级论证也干净:TS2305 成立、4 键全承接故零迁移、两侧 body 一字未改故不适用 C10/C16 的形状警示、tombstone 按 #4767 先例逐条评估后排除而非沉默跳过、strictness-ledger 以实跑结论决定不动台账。第三个 pin 用例(键集不相交断言 + 交叉粘贴 safeParse 双失败)把「两个概念」的前提本身钉住,将来有人让键集重叠会立即报红——这是个好设计。

---

Generated by Claude Code

[os-zhuang]

✅ 实施完成 —— draft PR #4789(分支 claude/issue-4741-package-dependency-dual-source,commit 464e4f1)。

路线复核结论:与先锋一致,无升级

按派发要求先自行以三仓 import 级实测复核真源,结论与先锋判定完全一致,故按既定裁决执行 D9(a) 改名 kernel 侧 → ResolvedPackageDependency(Schema),cloud 侧保名:

• 键集完全不相交(0 共享):cloud {packageId, versionRange, optional} 是声明形(嵌 PackageManifestSchema.dependencies[]);kernel {name, versionConstraint, type, resolvedVersion} 是解析形(嵌 DependencyGraphNodeSchema.dependencies[] + PluginSecurityProtocol)。是「两个概念同名」,不是「一个概念两处声明」,故不走收敛 + re-export。
• 三仓零外部 importer:objectstack 0(唯一读者是同文件两处)、cloud 0(全仓零命中,亦无手拷形状 → 无 followup)、objectui 0。零 importer ≠ 有死侧可删(spec 双源清账 C5:ActivationEventSchema(./kernel ≠ ./studio)—— 1 条 #4653),两侧各自被真实 schema 嵌入,都活着 ⇒ 改名而非删除。
• ⚠️ 派发单点名的误伤风险已规避:同前缀近邻 PackageDependencyConflict 与 PackageDependencyResolutionResult 一字未动,并由 pin 显式断言健在。

基线自证(#4650)

删行前门禁 stale 分支点名要求删除的正是这 2 行:

❌  2 stale baseline entries — no longer dual-source, delete the line(s):
    • PackageDependency — [./cloud (type)] ≠ [./kernel (type)]
    • PackageDependencySchema — [./cloud (const)] ≠ [./kernel (const)]

删行后(--update 规范形重写,非手编):

✅  no new dual-source exports: 4284 names across 16 entry points — 173 re-exported (single declaration), 1 accepted dual-source (baseline).

基线 3 → 1(交付时点 main 尚未合入 C17)。余下 1 行即 C17 #4768 的 ActionLocationSchema;C17 入队合并后本 PR 同步 main,基线 2 → 0,第二批收官。

RENAMED_DEFS 承接 kernel/PackageDependency → kernel/ResolvedPackageDependency,4 keys carry 全数健在(authorable-surface 净零位移)。

定级:major、零元数据迁移、零形状变更

逐条自证未照抄别簇:TS2305 成立 ⇒ major;4 键全承接 ⇒ 零迁移;两 schema body 一字未改 ⇒ 无 C10 式字段类型变更、无 C16 式词表拓宽,故无需该两类警示承载,但仍用 parse 把 .default('required') / .default(false) 钉住(#4666 盲区自卫)。无 tombstone / 无 ADR-0087 conversion —— 已按 #4767 retiredKey() 先例逐条评估后排除(无 key 退役),非沉默跳过。check:strictness-ledger 实跑结论为不动台账(与 C12/C17 先例一致),未反射式修改。

Sabotage(2 组,实跑证据见 PR)

• S1 复活被删声明 → pin(2 断言)+ build 阶段 RENAMED_DEFS 不变式 3 两层独立拦截。
• S2 禁止路线(./kernel re-export cloud 声明顶裸名)→ 用含 S2 的源码重建 dist 后实跑,确认 dual-source 门禁全绿(良性 re-export 173 → 175,多出的 2 个正是这条谎报),而 pin 的 holders 精确相等断言与承接表不变式 3 各自拦下。再次实证 C17 的发现:承接表能在 build 阶段拒绝对 dual-source 门禁不可见的语义谎报。

验证清单(全绿)

check:dual-source-exports ✅ · check:generated ✅ 8/8 · 源码审计组 7 项 ✅ · spec test ✅ 293 files / 7351 tests · spec typecheck ✅ · 全仓 typecheck ✅ 122 successful, 122 total

幽灵页 references/cloud/plugin-security.mdx 随 gen:docs 自愈(#4696 语境),cloud 侧 PackageDependency 归位 package-version.mdx。未碰 content/docs/releases/;changeset 已加(major)。

交付说明

draft PR 已开,状态与合并时机归 PM,未启用 auto-merge。入队时若 main 已推进:按 PM 更正用 git merge origin/main(非 rebase / force-push),并对基线 / authorable-surface / json-schema.manifest 三张 ratchet 一律取 main 版本后只重施本 PR 的一处改动 —— 尤其 json-schema.manifest.json 归 merge driver 管、合并不产生冲突标记,会静默复活别人蓄意删除的键,须以 gen:schema 实跑输出为准。

---

Generated by Claude Code

[os-zhuang]

✅ PM 入队验收通过(07:35Z):PR #4789 已转正并启用 auto-merge。合并即双源基线归零、#4535 第二批收官。

同步核验(本地实测):origin/main 是分支尖 b8a691363 的祖先;基线 entries: [] —— 0 行;delta 对 main 恰为 13 文件。

静默回退审计四项全清:#4783 的 31 行 data/DriverCapabilities [RETIRED] 完好、C10 的 system/EnvironmentArtifact* 零复活、C17 的 studio/ActionLocation 旧名零残留、本单 kernel/PackageDependency 旧名零残留。

冲突解法值得单独记一笔:renamed-defs.ts 的源码冲突,你按「C17 与本簇是两条独立改名条目、按时序并存」处理,而不是二选一 —— 承接表现有 6 条(C9/C12×2/C15/C17/C7)俱在。这是对的:承接表是累积台账,合并冲突里选一条就等于把别人已合并的改名从台账上抹掉,而不变式 1(旧 def 每个 key 必须在新 def 下存在)只在本次 build 产出时才校验,抹掉的那条不会报红 —— 这类静默丢失只有靠人肉判断拦住。已记入 #4535。

基线文件的 \uXXXX → UTF-8 重编码差异:同意不单独立单 —— 由 --update 生成器规范形写出、非手编,且基线已空、后续 churn 近零。

---

Generated by Claude Code