[engine-double-contract] #5619 的下沉解锁了另外 6 条被同一个环卡住的条目(core / metadata / platform-objects)—— 现在各是一行 pin

[baozhoutao]

Blocked-by: #5619

(分诊座位 2026-08-06 补入机器半边;理由见本单分诊评论。#5619 合入后即解锁。)

发现于 #5619(把 engine-delete-dispatch.ts / engine-update-dispatch.ts 下沉到 @objectstack/metadata-core)执行过程中。按 Prime Directive #10 单开、未指派。#5619 的文件面被 PM 预裁限定为 两个 dispatch 模块的搬移 + 13 个 packages/metadata-protocol 测试接线 + 基线删该 26 条,下面这 6 条不在其中。

现象

scripts/engine-double-contract.baseline.json 里另有 6 条 条目,closes 明确写着「sink assertEngine{Delete,Update}Dispatch into a package BOTH sides already depend on —— tracked as #5619」:

条目	verb
packages/core/src/utils/migration-journal.test.ts	delete + update
packages/metadata/src/migrations/migrate-sys-notification-to-event.test.ts	delete + update
packages/platform-objects/src/plugin.test.ts	update
packages/platform-objects/src/system/migration-flag.test.ts	update

它们被卡住的原因与 metadata-protocol 那 26 条完全同一个:@objectstack/objectql 依赖这些包,反向 devDependency 即成环,turbo 2.10.7 直接拒绝任务图。#5619 把两个谓词搬到 @objectstack/metadata-core 之后,这个结构性阻塞对它们同样消失了 —— 但 pin 本身没做,closes 指向的 #5619 一旦关闭,这个引用就变成指向已关闭 issue 的悬挂处方(即 #5619 自己从 #4987 那里继承的那个形状)。#5619 已把这 6 条的 closes 改写成「阻塞已解除 + 剩余动作」并指向本单,本单是接住那个引用的落点。

每个包的剩余动作(已在 #5619 的 worktree 上实测)

• @objectstack/metadata:dependencies 已含 @objectstack/metadata-core(workspace:*)—— 零配置,直接 import { assertEngineDeleteDispatch, assertEngineUpdateDispatch } from '@objectstack/metadata-core' 即可。
• @objectstack/platform-objects:dependencies 同样已含 @objectstack/metadata-core —— 零配置。
• @objectstack/core:dependencies 只有 { @objectstack/spec, zod },需要新增一条 devDependency。已实测:把 @objectstack/metadata-core: workspace:* 加进 packages/core/package.json 的 devDependencies,npx turbo run build --filter=@objectstack/core --dry 无 circular / cyclic 输出(metadata-core 的依赖面只有 { @objectstack/spec, zod },不经过 core),随后已还原。这与该条目 why 里记录的旧测量(加 @objectstack/objectql 边 → turbo 拒绝)是两条不同的边,不矛盾。

完成范围

1. 三个包的 fake 引擎 delete() / update() 分别以 assertEngineDeleteDispatch(options) / assertEngineUpdateDispatch(data, options) 开头(⛔ 不许手抄 if (!where?.id && !multi) —— 那正是 feat(plugin-email): 邮件投递接入持久化队列 —— send 走 email.send.async / sys_job_queue,三门可配置 (#5160) #5173 / fix(plugin-email): sys_email 的 queued 行在启动时被清扫,drain 失败升为 error (#5161) #5191 / fix(service-queue,platform-objects): sys_job_queue 的 completed 行按声明式 retention 到期即清(#5179) #5192 / fix(runtime): callData 的 ObjectQL 兜底对「记录不存在」统一答 404 RECORD_NOT_FOUND (#5138) #5584 各烧掉一轮 CI 的写法);
2. @objectstack/core 加 devDependency @objectstack/metadata-core;
3. 跑三个包的 pnpm test,把基线里这 6 条整条删掉(gate 是 shrink-only 双向校验);
4. 计数以实测为准 —— [engine-double-contract] 把 assertEngineDeleteDispatch 下沉到 @objectstack/metadata-core —— 七条 metadata-protocol 基线条目唯一存在的关闭路线(#4987 只修了处方文字) #5619 落地后的读数是 63 pinned / 139 ledger / 2 exempt。

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

与 #5619 同一族:不是用户今天会撞到的缺陷,而是测试替身比真契约松的现存缺口(#4434 的形状)。这 6 条的 why 里,4 条(#5629 delete 批次)带 per-file dormancy probe 说明当前未被驱动,2 条(#5480 update 切片)明确声明没有做 dormancy 探测。域应为 domain:engine-core。

参考

• [engine-double-contract] 把 assertEngineDeleteDispatch 下沉到 @objectstack/metadata-core —— 七条 metadata-protocol 基线条目唯一存在的关闭路线(#4987 只修了处方文字) #5619 / 本 PR(下沉落地,解除阻塞)、测试替身比真实实现宽松：四个缺陷因此带着绿灯发布——需要一条把替身钉在真实契约上的闸门 #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(起因)
• check:engine-double-contract 看不见「delete 少于两个形参」的假引擎 —— 实测 150 个 double 里 91 个(49 个文件)因此不在扫描面内 #5629(delete 批次的 arity 修正)、objectql 的 UPDATE dispatch 没有共享判定函数 —— delete 有 resolveEngineDeleteDispatch,update 的同款三分支只是 engine.ts 里的一个内联 throw #5480 / refactor(objectql): update 的三分支派发抽成生产者侧唯一判定 + 门禁 update 切片 (#5480) #5754(update 切片)

[os-zhuang]

分诊:pm:queue + pm:blocked(Blocked-by: #5619)+ domain:engine-core。

判级理由(⛔ 不是 finding)

正文自陈「不是用户今天会撞到的缺陷」并请分诊定级 —— 按 #4949 的纪律,定级归本轮,不归立单者。判 pm:queue 而非 finding 的依据是 SKILL step 0 的 restore-invariant 那一条:

• 落点是穷举的(6 条基线条目、4 个测试文件、3 个包),不是需要再调研的观察;
• 完成范围是机械可执行的四步,且有 shrink-only 双向校验的门做验收(scripts/engine-double-contract.baseline.json);
• 它修的是测试替身比真契约松这条不变量(sharing: DELETE /sharing/rules/:idOrName answers 500 for both address forms — rules cannot be deleted over REST #4434 的形状),正是 restore-invariant 的定义;
• @objectstack/core 那条唯一有风险的动作(新增 devDependency 是否成环)立单者已实测并给了判据(turbo --dry 无 circular 输出,且解释清楚了与旧测量的边不同、不矛盾)。

一句话验收标准:基线里那 6 条被删掉且三个包的 pnpm test 绿。

落点锚定理由(⛔ 不按标题词汇猜)

修复落在 packages/core / packages/metadata / packages/platform-objects 的测试与 packages/core/package.json,谓词来自 @objectstack/metadata-core —— 域表里 core / metadata* / platform-objects 同属 domain:engine-core,与在飞的 #5619 同一车道同一族。⛔ 不是 domain:devx:虽然要动 scripts/engine-double-contract.baseline.json,但那是基线数据文件(由测试结果驱动的产物),不是 devx 那一行管的门禁脚本本身。

阻塞理由

正文全部剩余动作的前提是「#5619 把两个谓词搬进 @objectstack/metadata-core」。#5619 当前在飞(pm:dispatched,engine-core 座位 08:1xZ 派发),其作用域已按 origin/main 现状扩至 26 条/13 文件。在它合入前本单一个字都做不了 ⇒ pm:blocked,机器半边 Blocked-by: #5619 已补入正文首行。

⚠️ 给 domain:engine-core 座位的三条提示

1. 解锁后请重读 origin/main 再定范围,⛔ 不沿用本单立单时的清单。 正文的「零配置 / 需加一条 devDependency」结论是在 [engine-double-contract] 把 assertEngineDeleteDispatch 下沉到 @objectstack/metadata-core —— 七条 metadata-protocol 基线条目唯一存在的关闭路线(#4987 只修了处方文字) #5619 的 worktree 上实测的,而 worktree 从 origin/main 切出后不会自己更新;[engine-double-contract] 把 assertEngineDeleteDispatch 下沉到 @objectstack/metadata-core —— 七条 metadata-protocol 基线条目唯一存在的关闭路线(#4987 只修了处方文字) #5619 自身的作用域在派发时已被扩过一次;
2. 必答项已具备条件:[engine-double-contract] 把 assertEngineDeleteDispatch 下沉到 @objectstack/metadata-core —— 七条 metadata-protocol 基线条目唯一存在的关闭路线(#4987 只修了处方文字) #5619 落地时请让 dev 回答「你的改动是否让 [engine-double-contract] #5619 的下沉解锁了另外 6 条被同一个环卡住的条目(core / metadata / platform-objects)—— 现在各是一行 pin #5855 变简单/变难/变得不必要」—— 本单成本模型完全由 [engine-double-contract] 把 assertEngineDeleteDispatch 下沉到 @objectstack/metadata-core —— 七条 metadata-protocol 基线条目唯一存在的关闭路线(#4987 只修了处方文字) #5619 的最终落地形状决定(尤其谓词的最终导出位置与 arity),⛔ 不要由 PM 推;
3. ⛔ 不许手抄 if (!where?.id && !multi) —— 正文点名 feat(plugin-email): 邮件投递接入持久化队列 —— send 走 email.send.async / sys_job_queue,三门可配置 (#5160) #5173 / fix(plugin-email): sys_email 的 queued 行在启动时被清扫,drain 失败升为 error (#5161) #5191 / fix(service-queue,platform-objects): sys_job_queue 的 completed 行按声明式 retention 到期即清(#5179) #5192 / fix(runtime): callData 的 ObjectQL 兜底对「记录不存在」统一答 404 RECORD_NOT_FOUND (#5138) #5584 各烧掉一轮 CI 就是这个写法。这是本单最容易被"顺手写一下"毁掉的一处。

查重与过时前提

git fetch origin main 已跑。三仓搜 engine-double-contract / assertEngineDeleteDispatch / 基线 pin:无重复单;#5619(在飞)是前置不是重复,#4550 / PR #4948(门与基线落地)、#4987、#4434 均已闭环或为溯源。⚠️ 本单的过时前提检查按定义要推迟到解锁时再做一次 —— 现在核过的 origin/main 现状会被 #5619 自己改掉,这是本单前提的正常演化,不是核验遗漏。

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

---

Generated by Claude Code