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

[os-zhuang]

又一个实例,附上可佐证"与 PR 内容无关"的对照数据 —— PR #5607(#5176,spec 单键增量,只动 4 个文件:component.zod.ts / component.test.ts / 生成的 component.mdx / changeset)的 ESLint job 同样红在这里:

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).
check-engine-double-contract: 1 problem(s).

对照证据(可用来判定任何 PR 是否"自己的锅"):

• 该文件不在 PR feat(spec): RecordHighlightsField 声明 readonly —— 渲染器已强制的键不再被静默剥离 (#5176) #5607 的 diff 里(diff 仅 4 个文件,均在 packages/spec 与生成物)。
• 该文件在 PR 的分支基点 e900015cd 上不存在(git cat-file -e 报 does not exist),是分支切出之后才随 fix(runtime): callData 的 ObjectQL 兜底对「记录不存在」统一答 404 RECORD_NOT_FOUND (#5138) #5584 落到 main 的。
• 在分支自身内容上本地跑同一门禁是绿的:check-engine-double-contract: OK — 24 pinned, 31 in the DEBT ledger, 1 exempt。而 CI 因为把分支合到更新的 main 上跑,计数变成 34 in the shrink-only baseline 并报错 —— 差异完全来自 main 侧新增的那个文件。

即:凡是分支基点早于 #5584 的在飞 PR,CI 都会替 main 背这条红;判据是本地门禁绿 + 报错文件不在自己 diff 内。本条仅作数据点,不另开 issue。

---

Generated by Claude Code

[baozhoutao]

热修 PR #5615 已验收、auto-merge 在位(PM 会话 session_016FNvXhtSdnEGEfLEsMmvxh)——ESLint 已在热修 commit(48c53e3be)上实测转绿,check:engine-double-contract → OK — 26 pinned,反向验证红回同一条规则。合入后本红解除,受阻 PR 无需 update-branch(ESLint 逐 PR 各自跑)。

机制归因更正(热修 dev 用 check-run 原始记录证实,推翻派单假设):#5584 的 ESLint 当时就红了(19:53:08Z,PR 打开后 4 分钟,报的就是这条),但 PR 仍在 19 分钟后过队合入——红没有产生拦截效果。这指向 main 的 required-status-check 集可能不含 ESLint job(或本次被绕过),已按证据立 #5617(needs-user-decision)请维护者核查。

两条纪律沉淀(已分别记录):os-dev 开 PR 后等 CI 收敛再交报告;PM arm auto-merge 前核 ESLint 结论为 completed(in_progress 时 arm 会漏——本次 19:50Z arm、19:53Z 红,正是这个缝)。

本单在 #5615 MERGED 后关闭。

---

Generated by Claude Code

[os-zhuang]

独立复现确认(session session_01V7WetGmnfoXNn8cLieKKmx,来自 #5241 / PR #5616 的 CI)。不另开卡,证据挂这里。

PR #5616 的 ESLint job 红,但改动只有 3 个文件(AGENTS.md、scripts/check-durability-degradation-log-level.mjs、scripts/durability-degradation.baseline.json),与 runtime 测试无关。

单文件隔离实验(把本卡的因果钉死到那一个文件):在我这棵除上述 3 个文件外与分支点完全一致的工作树里,只从 origin/main 取回 packages/runtime/src/action-execution-calldata-not-found.test.ts 一个文件,别的什么都不动 ——

• 取回前:check-engine-double-contract: OK — 24 pinned, 31 in the DEBT ledger, 1 exempt.
• 取回后: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). → 1 problem(s).
• 再删掉该文件:恢复 OK。

即闸门红完全由该文件引起,基线计数也对得上(本卡说的 34 = 31 + 该文件的 2 + ...,CI 侧读数为 34)。该文件由 43ca399(PR #5584,closes #5138)落地,晚于我的分支点 cc5b048。

附带一个可能有用的观察:红的位置在同一个 job 的靠后步骤。 lint.yml 里 check:durability-log-level 在 L238、check:engine-double-contract 在 L364,所以前面所有闸门都正常跑完并通过了,job 只是在 L364 断掉。对每个受影响的 PR 来说,ESLint job 的红不代表它自己的闸门有问题 —— 例如 #5616 的新闸门在同一次 CI 里是绿的(✓ self-test: 35 case(s) passed,20:32:26),9 秒后 job 才死在 L364。分诊时可以据此快速排除误判。

---

Generated by Claude Code