#4535 第二批。基线行:`PackageDependency(+Schema) — [./cloud] ≠ [./kernel]`。 **已裁决路线(前锋判定 + 维护者 2026-08-03 批复)**:D9(a) 改名 **kernel 侧** → `ResolvedPackageDependency`(备选 `PackageDependencyRequirement`,bikeshed 不阻塞);cloud 侧保名。 **前锋证据摘要**(详见 [#4535 前锋评论](https://github.com/objectstack-ai/objectstack/issues/4535#issuecomment-5161308046)):键集完全不相交(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
os-zhuang commentedon Aug 3, 2026
🔒 认领: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 commentedon Aug 3, 2026
✅ 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 commentedon Aug 3, 2026
✅ 实施完成 —— draft PR #4789(分支
claude/issue-4741-package-dependency-dual-source,commit464e4f1)。路线复核结论:与先锋一致,无升级
按派发要求先自行以三仓 import 级实测复核真源,结论与先锋判定完全一致,故按既定裁决执行 D9(a) 改名 kernel 侧 →
ResolvedPackageDependency(Schema),cloud 侧保名:{packageId, versionRange, optional}是声明形(嵌PackageManifestSchema.dependencies[]);kernel{name, versionConstraint, type, resolvedVersion}是解析形(嵌DependencyGraphNodeSchema.dependencies[]+PluginSecurityProtocol)。是「两个概念同名」,不是「一个概念两处声明」,故不走收敛 + re-export。objectstack0(唯一读者是同文件两处)、cloud0(全仓零命中,亦无手拷形状 → 无 followup)、objectui0。零 importer ≠ 有死侧可删(spec 双源清账 C5:ActivationEventSchema(./kernel ≠ ./studio)—— 1 条 #4653),两侧各自被真实 schema 嵌入,都活着 ⇒ 改名而非删除。PackageDependencyConflict与PackageDependencyResolutionResult一字未动,并由 pin 显式断言健在。基线自证(#4650)
删行前门禁 stale 分支点名要求删除的正是这 2 行:
删行后(
--update规范形重写,非手编):基线 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 —— 已按 #4767retiredKey()先例逐条评估后排除(无 key 退役),非沉默跳过。check:strictness-ledger实跑结论为不动台账(与 C12/C17 先例一致),未反射式修改。Sabotage(2 组,实跑证据见 PR)
RENAMED_DEFS不变式 3 两层独立拦截。./kernelre-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 commentedon Aug 3, 2026
✅ 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
feat(spec)!: 改名 kernel 侧 PackageDependencySchema → ResolvedPackageDep…
test(spec): kernel test titles state each cited decision in words ins…