objectql 的 UPDATE dispatch 没有共享判定函数 —— delete 有 `resolveEngineDeleteDispatch`,update 的同款三分支只是 engine.ts 里的一个内联 throw

[os-zhuang]

发现于 #5393(flow update_record / delete_record 补 multi 批量意图键)的实现过程,PR 见该单。属 PD #10 的范围外发现,不在 #5393 内修(#5393 的 scope guard 明写 packages/objectql 零改动)。

事实(origin/main)

delete 的派发决策已经被抽成生产者侧的唯一判定,任何测试替身都能 import 它:

• packages/objectql/src/engine-delete-dispatch.ts —— resolveEngineDeleteDispatch / assertEngineDeleteDispatch / scalarDeleteId / ENGINE_DELETE_REJECT_MESSAGE / ENGINE_DELETE_DISPATCH_CASES,全部从 @objectstack/objectql 导出;
• scripts/check-engine-double-contract.mjs 以「fake 的 delete 是否路由该判定」为门禁,当前 23 pinned / 32 DEBT / 1 exempt。

update 的同款三分支没有对应物:

• packages/objectql/src/engine.ts 的 update 路径里,标量 where.id → 按 id;否则 options.multi → driver.updateMany;否则 throw new Error('Update requires an ID or options.multi=true') —— 这条 throw 是内联字面量,既没有导出的常量,也没有可复用的判定函数。
• check-engine-double-contract.mjs 的文件头把这一条列为刻意不覆盖:"every other method a fake engine offers (find filter semantics, update's twin dispatch, unknown-option rejection). Same family, but each needs its own producer-side predicate extracted first. delete had one available because sharing: DELETE /sharing/rules/:idOrName answers 500 for both address forms — rules cannot be deleted over REST #4434 already paid for it."

为什么现在值得记

#5393 在 service-automation 里补真实契约测试时,delete 侧可以用 assertEngineDeleteDispatch 把假引擎钉死在生产者契约上(该文件已被门禁认作 pinned);update 侧只能退而断言执行器交给引擎的 options 包,并在文件头写明「不对引擎会不会接受它发表第二份意见」—— 因为唯一的替代做法是在 fake 里手抄一遍 update 的判定,而那正是 #4434 / #4550 记录的、门禁存在的理由(手抄必然漏掉 where: { id: { $in: [...] } } 看着像 id 其实是谓词这一半)。

也就是说:同一个执行器的两个写入动词,一个能被绑定到生产者契约,另一个结构上不能,而 update_record 的破坏性并不比 delete_record 低多少(谓词 update 覆盖整表字段)。

建议动作

1. 按 engine-delete-dispatch.ts 的形状抽出 engine-update-dispatch.ts:resolveEngineUpdateDispatch / assertEngineUpdateDispatch / ENGINE_UPDATE_REJECT_MESSAGE,让 ObjectQL.update 自身改用它(生产者与判定必须是同一份,否则又是第二份副本);
2. check-engine-double-contract.mjs 增加 update 切片,基线按实测填(不要 --fix 式生成);
3. 顺带可关掉 flow 的 delete_record / update_record 无法表达批量意图 —— 节点 schema 无键、执行器不传 options.multi,谓词批量写对所有 flow 平台级不可达,而节点描述符宣称支持 #5393 留下的这条不对称:packages/services/service-automation/src/builtin/crud-bulk-intent.test.ts 的 update 用例可以升级为同样 pinned。

注:@objectstack/objectql 已在 #5393 中加入 @objectstack/service-automation 的 devDependencies(无环:objectql 的传递依赖闭包 12 个包不含 service-automation),所以第 3 步不再需要额外的依赖变更。这一点也已回填到 scripts/engine-double-contract.baseline.json 里那 8 条 service-automation 条目的 why / closes。

关联:#5393(本发现来源)、#5197(检测器盲点:零参 async delete() 连发现都发现不了)、#4550(门禁本体)、#4434(家族起源)、#4987(metadata-protocol 侧的成环阻塞,与本单无关但同族)。

[os-zhuang]

认领:PM 循环第 3 轮(engine-core 车道)
会话:session_01V7WetGmnfoXNn8cLieKKmx
分支:claude/issue-5480-update-dispatch-predicate
Worktree:objectstack-issue-5480
域:domain:engine-core
文件面:新增 packages/objectql/src/engine-update-dispatch.ts、packages/objectql/src/engine.ts(仅 update 派发三分支改用新判定)、objectql 导出面与测试、scripts/check-engine-double-contract.mjs + scripts/engine-double-contract.baseline.json(update 切片,基线按实测填)、.changeset/*.md。
范围裁定:issue 的第 1、2 步为本单范围;第 3 步(service-automation 测试升级)⛔ 不做 —— packages/services/** 属 services 车道,本单落地后由该车道按 #5393 的既有线索自行升级(依赖已就位,零阻塞)。⛔ 不碰 lifecycle-service.ts(#5194 同批在飞)。

---

Generated by Claude Code

[os-zhuang]

PM 评审(会话 session_01V7WetGmnfoXNn8cLieMKmx 笔误更正:session_01V7WetGmnfoXNn8cLieKKmx):PR #5754 ACCEPT,待 CI 绿后放行。

已读 diff(门禁脚本与核心模块全文,基线 JSON 采样核验)。要点:

1. 生产者即判定:resolveEngineUpdateDispatch 把 engine.ts 原两行逐字搬入(data.id 真值直取、where.id 标量测试、真值分支),ObjectQL.update 自身改用它——不是第二份副本。reject 分支同時换成导出常量,注释说明为何在 hook 后重新问一次。
2. 照抄而非改良:data.id 不做标量测试、where:{id:0} 不走 by-id,两处 update≠delete 的差异都钉进测试并注明「修的时候两文件一起翻面」(ObjectQL.update 的 data.id 不做标量测试 —— 载荷里的算子对象被当成主键绑定,且盖过显式 options.multi: true #5748 已归档)。这正确执行了「判定不得比生产者聪明」的 测试替身比真实实现宽松：四个缺陷因此带着绿灯发布——需要一条把替身钉在真实契约上的闸门 #4550 原则。
3. 测试对照真实引擎:17 例逐例断言引擎实际行为==判定裁决;反向验证扰动的是引擎分支(独立的那一半),8 条 reject 全红且红在 real-engine 断言上——方向先判后跑,方法论合格。
4. 门禁切片化:SLICES 两事实结构、(file,verb) 键 + DECLARED 不变量(负向验证过)、driver-only 否决提到任意 arity(修正 19 个假驱动误报,delete 侧实测零变化)、自测补上「跨切片 predicate 不算 pin」——这条 fixture 是先证明第一版自测抓不到扰动后补的,含金量高。
5. 10 处 objectql 包内假引擎当场钉上,4 个本就钉 delete 的文件补齐了不对称——issue 由来的那个形状。
6. 范围纪律:第 3 步(service-automation)明确留给 services 车道,零阻塞交接;两个范围外发现按 PD chore: version packages #10 归档为 engine-delete-dispatch 的共享判定与 ObjectQL.delete 在「假值标量 id」上不一致 —— where: { id: 0 } 判定答 by-id,引擎却 reject #5747/ObjectQL.update 的 data.id 不做标量测试 —— 载荷里的算子对象被当成主键绑定,且盖过显式 options.multi: true #5748 而非顺手修。

CI 绿后我会转 ready 并挂 auto-merge。注意:#5619 与本 PR 共享门禁两文件,继续保持串行,#5754 落地后解锁;engine.ts 槽位同理(#5699/#5284 在后)。

---

Generated by Claude Code