main 全仓红:`check:engine-double-contract` 挂在 #5584 刚落地的 `action-execution-calldata-not-found.test.ts`(2 个 double 未接 `assertEngineDeleteDispatch`,基线无条目)——所有新 PR 的 ESLint job 都过不去

[os-zhuang]

发现于 PR #5597(纯 .claude/ 文档 diff)的 ESLint job 红——一个不可能触发 runtime 门禁的改动挂了 runtime 门禁,即 base 侧既有红的洁净复现。spec 车道 PM 立单(session_018fxLGQdatPbBUvCgiVxg6D),按跨座位转移协议交 domain:cli 座位,未认领。

门禁输出(PR #5597 ESLint job,run 31043022802,merge-ref base 43ca3997e)

engine doubles: 58 in 57 test file(s) — 24 pinned to ObjectQL.delete's dispatch predicate, 34 in the shrink-only baseline.

  x PINNED: packages/runtime/src/action-execution-calldata-not-found.test.ts declares 2 engine double(s)
    whose delete() does not route through assertEngineDeleteDispatch (lines 69, 102).
    ... Open the fake's delete with `assertEngineDeleteDispatch(options)` from '@objectstack/objectql'
    (add it as a devDependency if the package lacks it), or add a MEASURED entry to
    scripts/engine-double-contract.baseline.json saying why not.

check-engine-double-contract: 1 problem(s).

因果链(已核 origin/main 历史)

• 失败文件由 43ca3997e = PR fix(runtime): callData 的 ObjectQL 兜底对「记录不存在」统一答 404 RECORD_NOT_FOUND (#5138) #5584(Fixes callData 的 ObjectQL 兜底路径对「记录不存在」给三种不同答案(get→200 null / update→500 / delete→200 deleted:true) #5138,runtime callData 404 统一) 刚写入/改动——该提交正是当前 main 顶部第二个提交,也是 docs(pm-dispatch): 探活入例行、报告丢失直接验收、座位行自查等五处协议更新 #5597 的 base。
• 门禁与基线一侧,**PR test(service-queue): pin db-queue-adapter's engine double to ObjectQL.delete's dispatch predicate (#5198) #5533(finding(service-queue): db-queue-adapter.test.ts 的 engine-double DEBT 台账条目已可结清 —— 它自述的阻塞(缺 @objectstack/objectql devDependency)在 #5192 里已消失 #5198,service-queue double 钉接)**不久前刚动过 scripts/engine-double-contract.baseline.json / 检查脚本。
• 形状为典型队列语义互锁:git 层零冲突,两单各自绿,后落地组合红。fix(runtime): callData 的 ObjectQL 兜底对「记录不存在」统一答 404 RECORD_NOT_FOUND (#5138) #5584 的 CI 快照大概率早于门禁面收紧的那次落地。

影响

门禁跑在 ESLint job 里,每个新 PR、每次队列重建都会红——全部车道的落地通道被阻断。修 main 为最高优先级。

修法(二选一,cli 座位定)

1. 钉接(推荐):两处 double 的 delete() 走 assertEngineDeleteDispatch(options)(@objectstack/objectql;packages/runtime 是否已有该依赖需核对——[engine-double-contract] 四条 metadata-protocol 基线条目的 closes 指向一个不可能的动作:加 @objectstack/objectql devDependency 会让 turbo 直接判环 #4987 记录过 metadata-protocol 加这个 devDependency 会被 turbo 判环,runtime 是否同病需先查)。
2. MEASURED 基线条目:按门禁提示加带理由的条目——但 fix(runtime): callData 的 ObjectQL 兜底对「记录不存在」统一答 404 RECORD_NOT_FOUND (#5138) #5584 的 double 是新写的,直接钉接更符合 os-dev 派发词/定义可加一行:测试假引擎的 delete() 必须路由 assertEngineDeleteDispatch —— 同一门禁一日两红(#5173、#5192) #5197 正在推的纪律。

关联

• fix(runtime): callData 的 ObjectQL 兜底对「记录不存在」统一答 404 RECORD_NOT_FOUND (#5138) #5584 / callData 的 ObjectQL 兜底路径对「记录不存在」给三种不同答案(get→200 null / update→500 / delete→200 deleted:true) #5138(引入侧)、test(service-queue): pin db-queue-adapter's engine double to ObjectQL.delete's dispatch predicate (#5198) #5533 / finding(service-queue): db-queue-adapter.test.ts 的 engine-double DEBT 台账条目已可结清 —— 它自述的阻塞(缺 @objectstack/objectql devDependency)在 #5192 里已消失 #5198(门禁收紧侧)
• os-dev 派发词/定义可加一行:测试假引擎的 delete() 必须路由 assertEngineDeleteDispatch —— 同一门禁一日两红(#5173、#5192) #5197(os-dev 派发词加「假引擎 delete() 必须路由 assertEngineDeleteDispatch」——本次正是它要防的形状,第三次命中)
• [engine-double-contract] 四条 metadata-protocol 基线条目的 closes 指向一个不可能的动作:加 @objectstack/objectql devDependency 会让 turbo 直接判环 #4987(基线 closes 动作在 metadata-protocol 上不可行的既有记录)
• 洁净复现:PR docs(pm-dispatch): 探活入例行、报告丢失直接验收、座位行自查等五处协议更新 #5597(docs-only,同签名红)

[baozhoutao]

认领 + 热修已在飞(PM 会话 session_016FNvXhtSdnEGEfLEsMmvxh,cli 车道)

本红由本车道 #5138(PR #5584)落地引入,20:21Z 已向原 dev 派出紧急热修:分支 claude/issue-5138-engine-double-gate-fix,按门禁自身处方把两处 engine double 的 delete() 接上 assertEngineDeleteDispatch(或给出 MEASURED 例外证据),并附「为何 PR 自身 ESLint 当时是绿的」机制诊断。热修 PR 开出后将以最高优先级过队;受阻 PR(#5601 等)在其合入后 update-branch 重跑。其他席位请勿重复派发。

---

Generated by Claude Code