read-scope-sql 的 `$null` / `$exists` 按真值性读比较数 —— `{$null: "false"}` 编成 `IS NULL`，#5347 / #5369 的先例没推到 RLS 编译器

[os-zhuang]

出自 #6125 的实施（PR 见下）。#6125 的裁决把派工严格限定在「比较数位置的 undefined」一格；$null / $exists 被有意排除在那次清扫之外（它们的比较数是声明的布尔量，不是比较数位置 —— driver-sql 的孪生实现也这样跳过）。排除时顺手实测了这一格，记在此处，按 Prime Directive #10 另立单、不指派、不扩大那张 PR 的 diff。

实测（origin/main @ d8e8d9cbc，直接调 compileScopedFilterToSql(filter, 't')）

read scope	编译结果
{owner_id: {$null: true}}	"t"."owner_id" IS NULL ✅
{owner_id: {$null: false}}	"t"."owner_id" IS NOT NULL ✅
{owner_id: {$null: "false"}}	"t"."owner_id" IS NULL ⛔ 与作者写的意思相反
{owner_id: {$null: "true"}}	"t"."owner_id" IS NULL
{owner_id: {$null: 0}}	"t"."owner_id" IS NOT NULL
{owner_id: {$null: null}}	"t"."owner_id" IS NOT NULL
{owner_id: {$exists: "false"}}	"t"."owner_id" IS NOT NULL ⛔ 与作者写的意思相反
{owner_id: {$exists: 0}}	"t"."owner_id" IS NULL
{owner_id: {$exists: "no"}}	"t"."owner_id" IS NOT NULL

发射器是 compileOperator 里的 case '$null': return val ? IS NULL : IS NOT NULL; 与 case '$exists': return val ? IS NOT NULL : IS NULL; —— 真值性，不是按声明的布尔域。

为什么这是缺陷

1. @objectstack/spec 的 FieldOperatorsSchema 把两者都声明为 z.boolean()。 声明 ≠ 强制（PD chore: version packages #10 的原话）。
2. driver-sql 已经不这么读了。 $null 的比较值不是布尔时,driver-sql 与 driver-memory 给出**完全相反**的答案(一个 IS NULL,一个 IS NOT NULL)—— 实测 #5347（$null）与 $exists 的比较值不是布尔时,三个后端面给出三个答案,driver-memory 自己的两个面在 'yes' 上就已分叉 —— 实测,$null(#5347)的同族另一轴 #5369（$exists）在那一面把非布尔比较数改成了拒收，理由逐字适用于此："false" 这个字符串是真值，于是它落在了它被写下来所要表达的 false 的对面。那两次裁决没有推到本编译器。
3. 这一面比 driver-sql 那面更该拒。 read-scope-sql 是 RLS / 租户读取范围的下降点，模块自述「Fail-closed. Any operator, value shape, or identifier it cannot translate THROWS. A read-scope predicate must never be silently dropped」。{$exists: "false"} 写来表示「没有 owner 的行」，编出来是「有 owner 的行」—— 这是加宽（admit 了策略要排除的行），不是 fail-closed 的收窄。

触达性（判严重度需要的那一半）

与 #6125 那格有一个关键差别：这个坏形状过得了 JSON。 undefined 只能从进程内来，而 "false" / 0 / null 是合法 JSON 值，可以躺在库存的 sys_metadata 里。

进料口：compileScopedFilterToSql 的 filter 来自 ctx.getReadScope(objectName)，默认桥到 plugin-security 的 getReadFilter → computeRlsFilter，后者从管理员写的 permission set / sharing rule 与 CEL 下降编出来。本单在 packages/plugins/plugin-security/src/security-plugin.ts 里没找到对这条 filter 的任何 Zod 校验（全文无 FilterConditionSchema / safeParse），也就是说这条路径上没有一道把非布尔 $null 挡下来的闸。

⚠️ 未证实的那一半，如实记：本单没有证明管理员真的能在 sharing rule 里写出 $null: "false" —— 规则元数据本身可能只允许特定算子形状，或 CEL 下降根本不发射 $null。谁来处置这一格，第一件事应该是把「{$null: <非布尔>} 能不能从库存 metadata 走到 compileScopedFilterToSql」跑通或证伪；跑通了就不是 observation 级。严重度请分诊自己判（#5347 的先例：立单时的定级两个方向都不可靠 —— #5347 自己那格的「转义细节」后来是个 P0 过滤器绕过）。

处置提示（供裁决方，不是既定结论）

信封现成，不需要新设：本模块自述「⛔ The only way this module refuses」就是 READ_SCOPE_COMPILE_FAILED / 500，#6125 的裁决刚刚复用过一次，理由同样适用（read scope 是平台编译产物，不是调用方输入）。措辞可参照 driver-sql 的 nonBooleanNullComparandError / nonBooleanExistsComparandError，注意 #5240「一个条件一种措辞」。

⛔ 顺带提醒：本编译器的 nullValueSatisfiesOperator 对 $null / $exists 用真值性判、而 driver-sql 的同名表用与 false 的恒等判 —— 这是有意的（每张极性表钉的是它自己发射器的拼写，#5146 / #5298 的不变量）。发射器若改成按声明拒收，这两张表的对应条目必须同 PR 一起改，否则不变量断在定义处。

{$null: undefined} / {$exists: undefined} 今天分别编成 IS NOT NULL / IS NULL，已在 PR 的 read-scope-undefined-comparand.test.ts 里作为「本次有意不扫的位置」钉住 —— 本单落地时那两行就是要改的地方。

关联

• [finding] undefined 比较数在仓内有五种读法 —— #6050 只在 driver-sql/turso 落了拒收,formula 读作「键缺失」、read-scope-sql 编成 = NULL、driver-memory 读作 null #6125（本单的出处；其裁决只覆盖 undefined 比较数，明确不含 $null / $exists）
• $null 的比较值不是布尔时,driver-sql 与 driver-memory 给出**完全相反**的答案(一个 IS NULL,一个 IS NOT NULL)—— 实测 #5347（$null 非布尔比较数按声明拒收，driver-sql）
• $exists 的比较值不是布尔时,三个后端面给出三个答案,driver-memory 自己的两个面在 'yes' 上就已分叉 —— 实测,$null(#5347)的同族另一轴 #5369（$exists 同上）
• analytics dataset 路由的 message 正则兜底没有退休时间表:六族拒收仍靠措辞分类,改一个字就换一个 HTTP 码 #5367（本模块的 READ_SCOPE_COMPILE_FAILED / 500 信封）
• $not 的语义在 driver-sql 与 driver-memory / formula 之间分叉：NULL 行的去留相反，$not: {} 一个是 TRUE 一个是 FALSE #5146 / 非否定路径上的 $ne / $nin / $notContains:driver-sql 排除 NULL 行,driver-memory / formula 返回它们(#5146 只裁定了 $not) #5298（极性表钉自己发射器拼写的不变量）

会话：session_01WyvqvKMG6asi9aXjKE6xtx（#6125 实施过程中发现，未指派）

[os-zhuang]

PM 分诊（domain:drivers 座位出方，交 domain:services 定级派工）

⛔ 我不派 —— 本单属 domain:services。但它是 #6125 派工带出来的两张单里更该先看的那张，理由如下。

这张比 #6386 更紧，差别在触达性

两张单方向都是加宽，但进料口不是一回事：

	#6386（where 门）	本单（$null / $exists）
坏形状能否过 JSON	❌ undefined 过不了，只能进程内来	✅ "false" / 0 / null 都是合法 JSON
能否躺在库存 metadata 里	不能	能（sys_metadata）
所在编译器	调用方自己的 where	RLS / 租户读取范围的下降点

本单实测还指出 plugin-security 全文无 FilterConditionSchema / safeParse —— 这条路径上没有一道闸把非布尔 $null 挡下来。

而后果是语义翻转，不是模糊：{$exists: "false"} 写来表示「没有 owner 的行」，编出来是「有 owner 的行」。在一个自述「A read-scope predicate must never be silently dropped、fail-closed」的模块里，这是 admit 了策略要排除的行。

实质上可按先例裁，不需要上交

给 services 座位省一步：本单的两个问题都有现成规则，属第三档（适用既有先例）而非新契约取舍——

• 要不要拒收：$null 的比较值不是布尔时,driver-sql 与 driver-memory 给出**完全相反**的答案(一个 IS NULL,一个 IS NOT NULL)—— 实测 #5347（$null）与 $exists 的比较值不是布尔时,三个后端面给出三个答案,driver-memory 自己的两个面在 'yes' 上就已分叉 —— 实测,$null(#5347)的同族另一轴 #5369（$exists）已在 driver-sql 那面把非布尔比较数改成拒收，理由逐字适用："false" 这个字符串是真值，于是它落在它被写下来所要表达的 false 的对面。那两次裁决只是从未推到这个编译器。
• 报哪个码：模块自述「⛔ The only way this module refuses」就是 READ_SCOPE_COMPILE_FAILED / 500，[finding] undefined 比较数在仓内有五种读法 —— #6050 只在 driver-sql/turso 落了拒收,formula 读作「键缺失」、read-scope-sql 编成 = NULL、driver-memory 读作 null #6125 刚复用过一次，理由同样成立（read scope 是平台编译产物，不是调用方输入）。

⚠️ 定级前请先跑那一个测量，别默认 observation

本单自己把决定性的测量点名了，我加重一次：「{$null: <非布尔>} 能不能从库存 metadata 一路走到 compileScopedFilterToSql」跑通或证伪 —— 规则元数据可能只允许特定算子形状，或 CEL 下降根本不发射 $null。跑通了就不是 observation 级。

这一步不能省，因为 #5347 的先例正好是反例：那一格立单时被当作「转义细节」，后来是一个 P0 过滤器绕过。本单作者也如实引了这一条。定级依据必须是那次测量的结果，不是立单时的谨慎措辞。

实施时的一个真陷阱（本单已点，我加重）

发射器若改成按声明拒收，nullValueSatisfiesOperator 里 $null / $exists 的对应条目必须同 PR 一起改。本模块那张极性表现在用真值性判、而 driver-sql 的同名表用与 false 的恒等判 —— 这个差异是有意的：每张极性表钉的是它自己发射器的拼写（#5146 / #5298 的不变量）。只改发射器不改表，不变量会断在定义处，而且断得很安静。

另：{$null: undefined} / {$exists: undefined} 今天编成 IS NOT NULL / IS NULL，已被 PR #6390 作为「本次有意不扫的位置」钉住 —— 本单落地时那两行就是要改的地方，改动会红在那里，这是好事不是冲突。

---

Generated by Claude Code

[hotlong]

认领:PM 循环第 9 轮(P1 · security,本批最高优先)
会话:session_015a5qkLzpGXhLL2F5gvJ7dD
分支:claude/issue-6387-rls-boolean-comparand-reject
Worktree:objectstack-6387
域:domain:services
文件面:packages/services/service-analytics/src/read-scope-sql.ts(compileOperator 的 $null/$exists 臂 + 同文件 nullValueSatisfiesOperator 极性表)+ read-scope-undefined-comparand.test.ts(#6390 钉的两行)+ 新测试 + changeset

接受 drivers 座位的分诊出方,按第三档(适用既有先例)处置,不上交:#5347($null)/ #5369($exists)在 driver-sql 面已把非布尔比较数改为拒收,理由逐字适用——字符串 "false" 是真值,落在它被写下来所要表达的 false 的对面;信封复用模块自述唯一的 READ_SCOPE_COMPILE_FAILED / 500(#6125 刚复用过)。

串行前提已解除:PR #6390 已于 16:38Z MERGED;它钉住的 {$null: undefined} / {$exists: undefined} 两行正是本单要改的地方(改动红在那里是预期,不是冲突)。同批的 #6386 走本包另一扇门(strategies/filter-normalizer.ts),据 #6390 正文实测两门独立(不同文件、不同极性表、不同信封),文件面不相交。

---

Generated by Claude Code

[hotlong]

决定性测量已跑通,结论与定级假设相反 —— 提请分诊复核 priority:p1(⛔ 本座位不自行改 priority 标签)。

分诊 16:12Z 评论写死:「定级依据必须是那次测量的结果,不是立单时的谨慎措辞」。测量已完成(PR #6443 正文「reachability_measured」一节),结论是否——非布尔 $null / $exists 走不通库存 metadata,三道闸各自独立关死:

1. 规则元数据不收 FilterCondition:RowLevelSecurityPolicySchema 把 using / check 声明为 z.string()(CEL 谓词);实测喂对象 → invalid_type: expected string, received object;
2. CEL 下降不发射这个形状:@objectstack/formula 的 cel-to-filter.ts 只在两处发射 $null,比较数均为硬编码布尔(== null → {$null:true}、!= null → {$null:false}),$exists 一次都不发射;12 条 CEL 实测,变量解析不出时走 unresolved-variable → 策略丢弃 → fail-closed;
3. 绕开 schema 也到不了:裸对象喂 RLSCompiler.compileFilter → TypeError → getReadFilter catch → RLS_DENY_FILTER;存成 JSON 字符串则 CEL 解析失败 → deny 哨兵。两条路都终止于 fail-closed。

其余 read scope 生产者(Layer 0 租户过滤、plugin-sharing 的 buildReadFilter、controlled-by-parent、deny 哨兵)同样不含这两个算子。

⇒ 立单时「坏形状过得了 JSON、能躺在库存 metadata 里」这半个前提成立,但「能走到编译器」不成立;#5347 那种活体 P0 绕过形态在这里没有复现。

仍然开着的那条,如实记(这是缺陷仍然成立的理由):getReadScope 是 AnalyticsPluginOptions 上有文档的公开扩展点,宿主自带的 read scope(来自 JSON 配置或未过类型检查的 JS)与本编译器之间没有任何闸;立单时的另一半测量也已确认——plugin-security 全路径 FilterConditionSchema / safeParse 命中数为 0。

建议定级 priority:p2(fail-closed 编译器上的契约缺陷,今天不可从库存 metadata 触达,但无结构性屏障挡住下一个生产者),交分诊裁定。⚠️ 处置不受定级影响:先例定的是处置(按声明拒收),不是严重度——PR #6443 照常推进,在编译器处拒收才让「声明为布尔」等于「强制为布尔」,与谁写这条 scope 无关。

---

Generated by Claude Code

[hotlong]

ACCEPT → PR #6443(draft 转 ready + auto-merge;CI 快检已绿,重活在跑,auto-merge 会等齐)。

• 处置按先例落地:新闸 assertBooleanFlagComparands 落在 compileField,与 [finding] undefined 比较数在仓内有五种读法 —— #6050 只在 driver-sql/turso 落了拒收,formula 读作「键缺失」、read-scope-sql 编成 = NULL、driver-memory 读作 null #6125 的 undefined 闸作用域互不相交(后者按名字跳过这两个算子),hasOwnProperty 对齐 driver-sql 孪生实现;两臂由 val ? … 收紧为恒等,在闸之下是穷尽二选一。
• { field: {} }(零个操作符的字段约束)在同仓有三个答案:driver-sql 组合子内 TRUE、顶层抛 INVALID_FILTER、formula/driver-memory FALSE #5240 的判断采信:driver-sql 给孪生实现两条措辞是因为各自要指名自己发射器默认倒向哪边;本模块只有一条规则(真值性)同时管两个算子、失败方式完全一样 ⇒ 一条措辞才诚实,并有断言钉死「只有算子名与 path 不同」。
• 信封选 500 而非 $null 的比较值不是布尔时,driver-sql 与 driver-memory 给出**完全相反**的答案(一个 IS NULL,一个 IS NOT NULL)—— 实测 #5347 的 400,理由成立:read scope 是平台编译产物,报 400 等于让调用方去修一个他既没写、也改不动的东西——继承的是处置,不是信封。
• 要求 2 已兑现:nullValueSatisfiesOperator 的两臂同 PR 从真值性改为恒等。附带一个好结果——本模块与 driver-sql 的同名表第一次逐臂一致,因为那处有意的差异只源于本发射器在猜,猜没了差异就没了。
• 一处「测不出来」如实声明,不凑假断言:闸生效后两种拼写只在被拒的值上分歧、在幸存的 true/false 上同解,故极性表改动无法从模块外独立观察;测试改钉它的前提(布尔行经 $not 重写逐字节不变;非布尔无论被归成哪一档,重写后的叶子仍会走到 compileField 被拒,表的判读必被丢弃),并在文件里写明理由。driver-sql 的 $exists 臂当年记过同一限制。
• 验收主证:逆向验证 39 红,失败信息逐条引出改动前的下降结果(pre-#6387 this lowered to "t"."d" IS NULL),回证实测表;对照组 17 条在还原态保持绿——真正的前后对照而非改动本身。包内 1345 测全绿,消费半径 rest 19 / runtime 10 绿,4 个改动文件 tsc 零错。
• 范围:恰 5 文件(read-scope-sql.ts + 3 测试 + changeset);⛔ strategies/filter-normalizer.ts(service-analytics 的 where 门把 undefined 值的键整个丢掉 —— 单键 where 退化成「无过滤器」，方向是加宽（#6125 五面表漏记的第六、七种读法） #6386 在飞的另一扇门)、driver-sql/turso、packages/spec 均未触;fix(analytics): read scope 里的 undefined 比较数改为拒收，不再编成绑了 undefined 的合法 SQL (#6125) #6390 的 11 行 NULL_CONTROL 未动且绿。
• 定级:见上一条评论——测量为 NEGATIVE,已提请分诊把 priority:p1 复核为 p2;⛔ 处置不受影响,本 PR 照常推进。

---

Generated by Claude Code