Skip to content

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

Closed

Description

@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 扫描。

Activity

  1. self-assigned this
    on Aug 3, 2026
  2. os-zhuang commented on Aug 3, 2026

    @os-zhuang
    ContributorAuthor

    🔒 认领: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

  3. os-zhuang commented on Aug 3, 2026

    @os-zhuang
    ContributorAuthor

    ✅ 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

  4. os-zhuang commented on Aug 3, 2026

    @os-zhuang
    ContributorAuthor

    ✅ 实施完成 —— 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

  5. os-zhuang commented on Aug 3, 2026

    @os-zhuang
    ContributorAuthor

    ✅ 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions