[engine-double-contract] 把 assertEngineDeleteDispatch 下沉到 @objectstack/metadata-core —— 七条 metadata-protocol 基线条目唯一存在的关闭路线(#4987 只修了处方文字)

[os-zhuang]

发现于 #4987(台账处方文字修正)执行过程中。#4987 的文件面被显式限定为 scripts/engine-double-contract.baseline.json 的 why/closes 文字,下沉本身没有落点,故按 Prime Directive #10 单开、未指派。

现象

scripts/engine-double-contract.baseline.json 里现有 7 条 packages/metadata-protocol/** 条目,全部因为同一个结构原因无法 pin:

• protocol-publish-drafts-endpoint-gate.test.ts(api 不在 metadata 类型注册表里 —— Studio 直写路径完全不校验端点,publishPackageDrafts 也没有 E7 门 #5206)
• protocol-publish-drafts-org-scope.test.ts([engine-double-contract] 四条 metadata-protocol 基线条目的 closes 指向一个不可能的动作:加 @objectstack/objectql devDependency 会让 turbo 直接判环 #4987 修文字)
• protocol.runtime-authoring-gate.test.ts([engine-double-contract] 四条 metadata-protocol 基线条目的 closes 指向一个不可能的动作:加 @objectstack/objectql devDependency 会让 turbo 直接判环 #4987 修文字)
• protocol.save-flow-canonicalization.test.ts([engine-double-contract] 四条 metadata-protocol 基线条目的 closes 指向一个不可能的动作:加 @objectstack/objectql devDependency 会让 turbo 直接判环 #4987 修文字)
• sys-metadata-repository.draft-drain.test.ts([metadata-protocol] SysMetadataRepository.publishDraft() 把 draft 清理的全部失败都当「并发发布者已抽走」,静默留下一条永远 pending 的 draft 行 #4981)
• sys-metadata-repository.history-counters.test.ts([metadata-protocol] SysMetadataRepository 的 nextEventSeq()/nextItemVersion() 同样把读失败当「表还没建」，静默从 1 重新发号 —— #4825 在 canonical 路径上的同形缺陷 #4867)
• sys-metadata-repository.recorded-by.test.ts([engine-double-contract] 四条 metadata-protocol 基线条目的 closes 指向一个不可能的动作:加 @objectstack/objectql devDependency 会让 turbo 直接判环 #4987 修文字)

@objectstack/objectql 的 dependencies 含 @objectstack/metadata-protocol(workspace:*),所以反向加 devDependency 即成环,turbo 2.10.7 直接拒绝任务图(本轮 #4987 在 worktree 上实测复现,build 与 test 两个 task graph 都被拒,exit 1,随后回退):

 WARNING  Circular package dependency detected: @objectstack/objectql, @objectstack/metadata-protocol
  x Cyclic dependency detected:
  | 	@objectstack/objectql#build, @objectstack/metadata-protocol#build

#4987 已把这 7 条的 why/closes 全部改成实测的环 + 下沉路线,但下沉代码本身未做 —— 而三条早先已改好的条目(#4867 / #4981 / #5206)的 closes 写的是「tracked as #4987」。#4987 一旦按其真实文件面(仅台账文字)关闭,这个引用就指向一个只改了措辞的已关闭 issue。本 issue 就是接住那个引用的落点。

为什么下沉是可做的(已静态核实)

判据来自同文件 packages/spec/src/contracts/data-engine.test.ts 那条 EXEMPT:反向 import 不可行时,唯一出路是下沉到两边都已依赖的包。

• 生产者 packages/objectql/src/engine-delete-dispatch.ts(168 行)没有任何 import —— 纯自包含模块,导出 ENGINE_DELETE_REJECT_MESSAGE / EngineDeleteDispatch / EngineDeleteDispatchInput / scalarDeleteId / resolveEngineDeleteDispatch / assertEngineDeleteDispatch / EngineDeleteDispatchCase / ENGINE_DELETE_DISPATCH_CASES。下沉是一次搬移,不是重构。
• @objectstack/metadata-core 是现成共同依赖:objectql -> metadata-core(workspace:*)与 metadata-protocol -> metadata-core(workspace:*)都已存在;metadata-core 的 dependencies 只有 { @objectstack/spec, zod },不含 objectql,故不引入新环。
• @objectstack/spec/contracts 是另一候选(spec 的 dependencies 只有 { zod }),但仅当「该谓词属于契约层」成立时才对 —— 需要拍板,不要顺手选。

完成范围

1. 把 engine-delete-dispatch.ts 搬到 @objectstack/metadata-core(或拍板后的 spec/contracts),@objectstack/objectql 改为 re-export 以保持现有 24 个 pinned 调用点与公共 API 不变。
2. 7 个 metadata-protocol 测试文件的 fake delete() 接上该谓词(从新落点 import),跑 @objectstack/metadata-protocol 套件 —— 注意其中若有 fixture 断言 predicate delete 成功,真引擎是拒绝的,按 flow 的 delete_record / update_record 无法表达批量意图 —— 节点 schema 无键、执行器不传 options.multi,谓词批量写对所有 flow 平台级不可达,而节点描述符宣称支持 #5393 之后可用 multi: true 表达。
3. 从基线里删掉这 7 条(gate 是 shrink-only 双向校验:文件已无 unguarded double 时条目必须整条消失),pnpm check:engine-double-contract 计数从 24 pinned / 34 baseline 变为 31 pinned / 27 baseline。
4. 顺带(在本 issue 范围内,不必另开):[metadata-protocol] SysMetadataRepository 的 nextEventSeq()/nextItemVersion() 同样把读失败当「表还没建」，静默从 1 重新发号 —— #4825 在 canonical 路径上的同形缺陷 #4867 / [metadata-protocol] SysMetadataRepository.publishDraft() 把 draft 清理的全部失败都当「并发发布者已抽走」,静默留下一条永远 pending 的 draft 行 #4981 / api 不在 metadata 类型注册表里 —— Studio 直写路径完全不校验端点,publishPackageDrafts 也没有 E7 门 #5206 三条的 closes 里「tracked as [engine-double-contract] 四条 metadata-protocol 基线条目的 closes 指向一个不可能的动作:加 @objectstack/objectql devDependency 会让 turbo 直接判环 #4987」应改指本 issue;这三条还写着「the four/five sibling metadata-protocol entries」,而现在同族共 7 条(各有 6 个 sibling)—— 硬编码计数已漂移。[engine-double-contract] 四条 metadata-protocol 基线条目的 closes 指向一个不可能的动作:加 @objectstack/objectql devDependency 会让 turbo 直接判环 #4987 修的四条已改用免计数措辞(「every other metadata-protocol entry in this ledger」)以避免再漂。若第 3 步整批删除,这两处随之消失。

影响(如实说明,请分诊定级)

不是用户今天会撞到的缺陷,而是测试替身比真契约松的现存缺口:这正是 #4434 让一整段 REST 路由死掉而套件全绿的形状,gate(#4550)就是为消除它而建。7 个文件里的 fake delete 目前可以接受真引擎会拒绝的调用。域应为 domain:engine-core(搬移生产者模块 + 改 7 个测试)。

参考

• 测试替身比真实实现宽松：四个缺陷因此带着绿灯发布——需要一条把替身钉在真实契约上的闸门 #4550 / PR feat(objectql): 把假引擎钉在 ObjectQL.delete 的真实契约上 (#4550) #4948(gate 与基线落地)、sharing: DELETE /sharing/rules/:idOrName answers 500 for both address forms — rules cannot be deleted over REST #4434(起因)
• [engine-double-contract] 四条 metadata-protocol 基线条目的 closes 指向一个不可能的动作:加 @objectstack/objectql devDependency 会让 turbo 直接判环 #4987(本 issue 的来源:台账处方文字修正)、[metadata-protocol] SysMetadataRepository 的 nextEventSeq()/nextItemVersion() 同样把读失败当「表还没建」，静默从 1 重新发号 —— #4825 在 canonical 路径上的同形缺陷 #4867 / PR fix(metadata-protocol): never invent event_seq/version from a failed history read (#4867) #4980、[metadata-protocol] SysMetadataRepository.publishDraft() 把 draft 清理的全部失败都当「并发发布者已抽走」,静默留下一条永远 pending 的 draft 行 #4981、api 不在 metadata 类型注册表里 —— Studio 直写路径完全不校验端点,publishPackageDrafts 也没有 E7 门 #5206
• objectql 的 UPDATE dispatch 没有共享判定函数 —— delete 有 resolveEngineDeleteDispatch,update 的同款三分支只是 engine.ts 里的一个内联 throw #5480(objectql 的 UPDATE dispatch 无共享判定函数 —— 相邻不同题:那条是 update 侧缺函数,本条是 delete 侧函数位置错)

[os-zhuang]

分诊:入队 pm:queue + domain:engine-core + pm:blocked。

• 落点锚定:搬移 packages/objectql/src/engine-delete-dispatch.ts → @objectstack/metadata-core(objectql 保留 re-export)+ 7 个 packages/metadata-protocol 测试接线 + 基线删 7 条 —— objectql / metadata* 家族 → domain:engine-core。默认落点 metadata-core 已静态核实不成环,spec/contracts 仅在维护者主动拍板时改道,不阻塞派发。
• Blocked-by: [engine-double-contract] 四条 metadata-protocol 基线条目的 closes 指向一个不可能的动作:加 @objectstack/objectql devDependency 会让 turbo 直接判环 #4987(在飞,domain:devx,其 PR 改同一份 scripts/engine-double-contract.baseline.json 的 7 条 why/closes 文字;先落它,本单再整批删条目,避免同文件冲突。[engine-double-contract] 四条 metadata-protocol 基线条目的 closes 指向一个不可能的动作:加 @objectstack/objectql devDependency 会让 turbo 直接判环 #4987 关闭后解锁回队)。
• 同文件在飞提示:main 全仓红:check:engine-double-contract 挂在 #5584 刚落地的 action-execution-calldata-not-found.test.ts(2 个 double 未接 assertEngineDeleteDispatch,基线无条目)——所有新 PR 的 ESLint job 都过不去 #5604(在飞,main 红止血)也在动同一基线(calldata 测试 2 条 double)。接续本单时按 SKILL 实测坑位第 8 条,先 git log --oneline origin/main -- scripts/engine-double-contract.baseline.json 复核在飞期间的变化再动手。
• 查重:objectql 的 UPDATE dispatch 没有共享判定函数 —— delete 有 resolveEngineDeleteDispatch,update 的同款三分支只是 engine.ts 里的一个内联 throw #5480(update 侧缺共享判定函数)相邻不同题;os-dev 派发词/定义可加一行:测试假引擎的 delete() 必须路由 assertEngineDeleteDispatch —— 同一门禁一日两红(#5173、#5192) #5197(os-dev 派发词提示)不重复;三仓无 shadow。

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code

[baozhoutao]

解锁 sweep(engine-core 车道 PM,会话 session_019Q7oc7ASjh8yxyS3Yz78We):Blocked-by: #4987 已于 2026-08-05 21:12Z 关闭(completed),摘 pm:blocked 回队,列为本车道下轮队首候选。

接续预记(SKILL 实测坑位第 8 条):派发前先 git log --oneline origin/main -- scripts/engine-double-contract.baseline.json 复核在飞期间变化 —— 今日 #5754(#5480)已动过该基线(update 切片条目),7 条 metadata-protocol 条目的现状措辞与计数一律以 origin/main 为准,issue 正文的 24 pinned / 34 baseline 计数可能已漂移。另:搬移涉及 packages/objectql 的 re-export 面,与本轮在飞 #5284(同包 engine.ts)跨轮串行。

---

Generated by Claude Code