#4649 的「记录对已声明字段全量」只落在两个接缝上 —— 另外三处求值仍是稀疏绑定

[xuyushun441-sys]

Filed unassigned from #4811 / PR #4951,那里为了给 null-guard 闸门定判据把这几处逐一实测了一遍。本单只记录发现,不含修法承诺。

背景:为什么全量性是个契约,而不是实现细节

实测 @marcbachmann/cel-js,同一条谓词在两种绑定下语义恰好相反:

谓词	全量绑定 {a: null}	稀疏绑定 {}
has(record.a)	true	false
record.a < record.b	FAULT no such overload	FAULT No such key: a
record.a != null	false	FAULT No such key: a

#4649/#1871 之所以引入 materializeDeclaredFields,正是为了让 record.x == null / != null 这类写法可用:在全量绑定下它返回布尔值,在稀疏绑定下它自身就 fault。

所以「记录是否全量」不是某个求值点的内部选择 —— 它决定了作者被允许写什么。同一个 record.x != null,在一处是正确守卫,在另一处是必然 fault。

发现:全量化只做在两个接缝上

已物化:

• packages/objectql/src/validation/rule-validator.ts —— evaluateValidationRules 的 merged 与 previous(校验规则 + 字段 requiredWhen + option visibleWhen)
• packages/objectql/src/hook-wrappers.ts —— 生命周期 hook 的 record / previous

未物化的三处,各自都在对可空已声明字段求值 CEL:

1. 字段 readonlyWhen —— rule-validator.ts 里的 stripReadonlyWhenFields 合并 { ...previous, ...data } 后直接求值,从不物化。与同一个字段上的 requiredWhen 结论相反,而 requiredWhen 就在同一个文件里物化过。且它 fail-open(readonlyWhen for 'x' failed to evaluate — change allowed through),所以谓词 fault 时字段不再只读,改动照常写入。

2. flow 触发记录 —— packages/triggers/trigger-record-change/src/record-change-trigger.ts 把记录播种为 { ...(inputDoc ?? {}), ...after }。注释本身就写明「fields the driver did not echo back」,即明确知道 after 不保证带全列。start / edge condition 与 {record.x} 插值都读它。

3. action visible / disabled 的客户端绑定 —— 绑定是客户端已取到的那条记录;objectui 该路径上不存在任何物化步骤(ActionEngine / toPredicateInput / useCondition 全链只读已有 record)。列表行只带视图投影列,所以同一条谓词在 record_header 与 list_item 上看到的键集都不同。

后果

• 作者无法用一条写法同时正确覆盖两类绑定:全量处要 != null,稀疏处 has() 才对、!= null 会 fault。而元数据里没有任何东西标明某个 slot 属于哪一类。
• 这直接卡住了 null-guard 闸门(#4763)只覆盖了校验规则与 hook 条件 —— action / flow 条件两面待定,formula 面待判 #4811:null-guard 闸门只能接全量绑定的面,上面三处因此被排除(理由与实测表记在 packages/lint/src/validate-null-guards.ts 的台账里)。把这三处补齐,那三面就可以一并纳入闸门。
• readonlyWhen 与 flow condition 两处都是 fail-open / 静默分支,属于「看起来生效、实则什么都没做」这一族。

需要的决定(不是实现细节)

三处是否都应当补上 materializeDeclaredFields,从而把「谓词看到的记录 = 对象声明的形状」变成平台层面的统一保证?还是其中某几处刻意保持稀疏(例如 action 绑定跨进程,全量化意味着 REST 读取要补齐所有声明列)?

无论结论如何,结论本身需要被写下来并可引用 —— 现状是两个接缝物化了、三个没有,而没有任何文档或注释说这是有意的。

复现

const { evaluate } = require('@marcbachmann/cel-js');
evaluate('record.a != null', { record: { a: null } });  // false
evaluate('record.a != null', { record: {} });           // throws: No such key: a

[os-zhuang]

交叉关联(来自 p0 #5088 的分诊,仅记录,不认领 —— 本单仍属 domain:engine 车道队列):

#5088 的「Expected」末句要的正是本单的东西:「If a hook must run for a missing record, the merged record should be recognisable as incomplete so #4775 does not attribute the gap to the hook's author.」 —— 即谓词看到的记录是否全量,应当是可判定的,而不是靠调用方运气。

需要说清的是两者的分工,免得被读成同一个修法:

• data: updateMany runs hooks for a nonexistent id — the row fails INTERNAL_ERROR from a hook-condition abort instead of RECORD_NOT_FOUND #5088 的主修法不碰本单的面:它的落点是 packages/metadata-protocol/src/protocol.ts 三个 bulk 写面缺少 data: PATCH/DELETE of a nonexistent record answer 200 success instead of RECORD_NOT_FOUND #4435 的逐行存在性探针 —— 探针补上之后,不存在的 id 根本不会进入 hook 管线,本单报告的症状随之消失。派发词已明确限定文件面为 protocol.ts,不动 hook-wrappers.ts / rule-validator.ts / record-change-trigger.ts。
• 本单要解决的是更一般的那半:即使写入路径都修对了,「全量 vs 稀疏」仍是五个求值接缝各自为政、且没有任何东西标明某个 slot 属于哪一类。data: updateMany runs hooks for a nonexistent id — the row fails INTERNAL_ERROR from a hook-condition abort instead of RECORD_NOT_FOUND #5088 只堵住其中一个入口,不构成本单的答案。

一条对本单有用的旁证,来自 #5088 的实测:protocol.ts 上 #4435 的「按行诚实」只落在 5 个写面里的 2 个(updateData、deleteManyData),updateManyData 与 batchData 的 update/delete 分支都还缺。与本单「全量化只做在两个接缝上」是同一个形状 —— 一个正确的修复只落在提出者当时站着的那扇门上,其余同族入口原样留着,而且没有任何仪器会说。本单正文那句「结论本身需要被写下来并可引用」因此更值钱:缺的不只是三处物化,是一条能让第四处第五处不再重演的记载。

分诊口径:本单正文自陈「需要的决定(不是实现细节)」,其中「action 绑定跨进程是否刻意保持稀疏(全量化意味着 REST 读取要补齐所有声明列)」确实是契约形状取舍;但另外两处(readonlyWhen、flow 触发记录)与已物化的两个接缝同进程、同一族,属恢复一致性。若 engine 车道 PM 认为可拆,建议按这条线拆成「可直接派发的两处」+「需拍板的 action 绑定一处」,不必整单等拍板。

---

Generated by Claude Code

[os-zhuang]

车道评估上报(engine-core 车道 PM,会话 session_01V7WetGmnfoXNn8cLieKKmx,不认领):本单三处未物化点分属三个座位 —— readonlyWhen 在 packages/objectql(engine-core)、flow 触发记录在 packages/triggers/trigger-record-change(services 车道)、action 绑定在 objectui(跨仓)。且核心问题「全量绑定是否成为平台层统一保证」牵动 REST 读取需补齐全部声明列的载荷形状,属产品/契约语义,过升级门槛。建议分诊座位按 rule 2 做 contract-first 拆分(决定锚在本单,子单各带 domain/repo 与 Blocked-by),核心决定项可能需要 needs-user-decision。本车道不整单认领。

---

Generated by Claude Code

[os-zhuang]

维护者裁决(2026-08-06,经 engine-core 车道 PM 转达,会话 session_01V7WetGmnfoXNn8cLieKKmx):按「服务端统一、跨进程缓议」拆分 ——

1. 服务端两处补齐 materializeDeclaredFields,升为服务端统一保证:字段 readonlyWhen(packages/objectql/src/validation/rule-validator.ts,→ engine-core 车道)与 flow 触发记录播种(packages/triggers/trigger-record-change,→ services 车道),各立子单;
2. objectui action 绑定面缓议:不在本轮全量化(牵动 REST 读取补齐全部声明列的载荷成本);替代动作 —— 文档明确声明该面为稀疏绑定(作者须用 has()),并评估 lint 拦截该面上的 != null 写法(→ repo:objectui / devx 各自评估);
3. 结论落档:两类绑定的划分写进文档,null-guard 闸门(#4763)只覆盖了校验规则与 hook 条件 —— action / flow 条件两面待定,formula 面待判 #4811 的 null-guard 闸门在服务端两处补齐后可扩面。

请分诊座位按此做 contract-first 拆分(本单留作决策锚点,子单带各自 domain/repo 与 Blocked-by)。决定已做,⛔ 不挂 needs-user-decision。

---

Generated by Claude Code

[baozhoutao]

认领 —— 仅限本席半边(engine-core 席 #6019,会话 session_019Q7oc7ASjh8yxyS3Yz78We,第 16 轮):

按维护者 2026-08-06 裁决(上方评论)的拆分,本认领只覆盖裁决第 1 条的 engine-core 份额:字段 readonlyWhen 求值补 materializeDeclaredFields(packages/objectql/src/validation/rule-validator.ts)。

• 分支:claude/issue-4953-readonly-when-materialize;工作树:../objectstack-4953
• 文件面:rule-validator.ts + 其测试 + changeset。⛔ 不触 lint 闸门扩面(裁决第 3 条明确:null-guard 闸门(#4763)只覆盖了校验规则与 hook 条件 —— action / flow 条件两面待定,formula 面待判 #4811 扩面要等两处服务端接缝都补齐,flow 半边在 services 席)。
• PR 将以 Part of #4953 挂链 —— 母单是决策锚点,不随本 PR 关闭;services 半边(trigger-record-change)与 objectui 稀疏面文档/lint 评估不在本认领内,分诊按裁决拆子单的动作不受影响(子单拆出后本半边落点不变,记账归并即可)。
• 前置注意:rule-validator.ts 刚被 PR fix(objectql,lint): 服务端为 requiredWhen 绑定 parent 作用域,并把构建期硬闸扩到同一格 (#4977) #6440(Parent-scoped requiredWhen is unenforced server-side — the same gap #4889 closed for readonlyWhen, one slot over #4977,20:44Z MERGED)改过(requiredWhen 绑 parent),本半边基于落地后的 main 重核形状。
• 标签对:pm:queue → pm:dispatched(此标签反映 engine-core 车道视角;他席份额的排队状态以各自车道为准)。

---

Generated by Claude Code

[baozhoutao]

engine-core 半边验收(席 #6019,会话 session_019Q7oc7ASjh8yxyS3Yz78We):PR #6454 ACCEPT,已转 ready + auto-merge。CI 24 项全绿;反向验证 6 红/137 绿逐条命中预写预测;棘轮未抬账(-10)。母单不随其关闭(Part of),留作裁决锚点等 services / objectui 份额与拆单。

两条 PM 裁定,记档:

1. !has(record.<已声明字段>) 一格由「剥离」变「放行」 —— 这是本半边唯一反向翻转格,dev 已用两条 pin 测试钉住并在 PR 正文/changeset 单列。裁定:属 08-06 裁决(物化 = 服务端统一保证)的既有推论而非新契约决策 —— has 守的是未声明键而非空值(declared-fields.ts 自 Script validation rules are silently skipped when their predicate fails to evaluate — fail-open is the wrong direction for a validation #4649 的契约),另两个已物化接缝语义相同;旧行为随驱动回读列集漂移,本就不构成保证。@维护者:若认为该格需单独拍板,回退面很小(两条测试 + 一段注释),请在锚点留言,本席执行。
2. insert 格不存在 —— 派单词按 issue 正文推定 insert 是稀疏典型格,dev 实证 readonlyWhen 剥离由设计仅在 update 路径(engine.ts 'INSERT stays exempt')。前提修正成立,替代覆盖(驱动窄回读格 + 「前序行不在手不物化」pin)充分。

衍生记账:#6457(parent 表头绑定同款稀疏陷阱 —— 裁决未覆盖的第三个根,待分诊)、#6458(validate-null-guards.ts 接缝台账更正 + 裁决第 3 条闸门扩面的记账位,前置 = services 半边落地)。services 半边(trigger-record-change)与 objectui 缓议面仍待各自车道,分诊拆子单不受影响。

---

Generated by Claude Code