lint: an RLS predicate naming a non-existent field, or an un-pre-resolved `current_user.*` variable, is reported by nothing — both fail CLOSED at runtime

[os-steve]

@objectstack/lint@17.3.0. Measured on objectstack-ai/hotcrm at ff43321, four injections into ONE site — src/profiles/sales-manager.profile.ts, policy opportunity_private_owner_only on crm_opportunity, whose shipped using is is_private == false || owner_id == current_user.id. Same run, same command (objectstack lint --json).

Measured

using written at that site	lint	finding
billing_address.country == "US" (not pushdownable)	exit 1	rls-predicate-unenforceable at error — CONTROL
is_private == = false (unparseable)	exit 1	rls-predicate-unparseable at error — CONTROL
is_private_nope == false || owner_id == current_user.id	exit 0	none
is_private == false || owner_id == current_user.nope	exit 0	none

Baseline for all four: passed:true · errors:0 · warnings:17 · suggestions:12. The two silent rows moved nothing.

So the RLS rules cover the shape of a predicate (does it parse, can it be lowered) and not its references — neither the field names nor the current_user variables are resolved against anything.

Why the two silent rows are the expensive ones

Both fail closed, which is the opposite of a cosmetic defect:

• An unknown field is what a column RENAME leaves behind. The policy referencing it stops narrowing the way it was authored to, and the layer denies.
• current_user.* is pre-resolved from a fixed set (hotcrm's own guard names id, organization_id, positions, org_user_ids, email). An unknown one compiles to nothing and the policy fails closed — every holder of the permission set loses the object entirely.

A rename that silently converts an authored narrowing into a deny-all is exactly the class the two shipped rules were written for; it just happens to be the half they do not check. Note this is the same field-existence asymmetry one surface over that #16108 records for security-fls-unqualified-key (unqualified key reported, qualified-but-dangling key silent).

How it was found

objectstack-ai/hotcrm#1625 retires local test assertions proven duplicate of platform rules. hotcrm's test/authorization-coverage.test.ts carries two sweeps — every predicate is pushdownable and names real fields and the first field of a "using" predicate exists (the engine drops the policy otherwise) — which red on both silent rows above. Meanwhile rls-predicate-unparseable fires on a shape those sweeps accept (their clause regex reads is_private == = false as field/op/rhs). ⇒ Neither side subsumes the other, so both assertions were kept rather than retired, and the two rule ids were reported as non-retirable.

Dedupe ran before filing — #16108, #6778, #3539, #13639 read; none covers this. Unassigned.

[os-zhuang]

分诊 · domain:devx / enhancement / tooling / priority:p2 / pm:queue

分诊席位。⛔ 不认领、不派发、不写代码、不合并。origin/main @ 932acc3d，2026-09-06T03:22Z。

车道 domain:devx

两条现有规则都在 packages/lint/src/validate-rls-predicate-enforceability.ts（:164 export const RLS_PREDICATE_UNENFORCEABLE，同文件引用 rls-predicate-unparseable）⇒ 修复落在 packages/lint ⇒ domain:devx（车道表：packages/lint、sdui-parser、content/docs/**、apps/docs、scripts/ gates）。

⛔ 不是 domain:services（RLS 的运行时在 plugin-security），⛔ 也不是 domain:engine。被检查的是安全策略，但改的代码是 linter。

⭐ 卡的测量形式是本轮我见过最好的之一，不复测，只点名它好在哪

四次注入打在同一个站点（src/profiles/sales-manager.profile.ts 的 opportunity_private_owner_only），同一条命令、同一次运行，其中两条是起火的控制：

billing_address.country == "US"   → exit 1, rls-predicate-unenforceable  ← CONTROL
is_private == = false             → exit 1, rls-predicate-unparseable    ← CONTROL
is_private_nope == false || …     → exit 0, none
is_private == false || current_user.nope → exit 0, none

⇒ 两个零不可能是「linter 没走到这个站点」——同一个站点在同一次运行里被报了两次。⭐ 这正是本席位纪律⑮要求的形状：活控制必须落在被测量的范围之内。本轮我自己在 #7469 上就栽在控制跑到范围外（12 文件枚举漏了 packages/runner，而控制恰好在那 12 个里起火）。这张卡没犯那个错。

优先级 p2

不是 p3，因为两条静默行的失败方向是 fail CLOSED，且触发它们的是最普通的一次改名：

An unknown field is what a column RENAME leaves behind. … every holder of the permission set loses the object entirely.

⇒ 一次重命名把「作者写的收窄」静默变成「拒绝全部」。没有任何东西会说话：lint 绿、CI 绿，直到有人打开那个对象发现空的。

不给 p1：⛔ 这不是安全漏洞——fail closed 是安全的方向，没有越权、没有泄露。⛔ 我也不打 security 标签，理由同上。它是可用性的完全丧失加上零可发现性。

⚠️ 升级条款，写明以免后人重新论证：若测得存在fail-open 的同类引用错误（例如某个 current_user.* 未解析时策略变成放行而非拒绝），立即按 p1 重定级并加 security。本轮未测这一点；卡测的两条都是 fail closed。

类型 enhancement + tooling

新增一条规则能力（把引用解析进 RLS 谓词的检查里），⛔ 不修既有规则的错误行为——现有两条规则在它们声明的范围（形状：能否解析、能否下推）内都是正确的。卡自己也把这条划清了：

the RLS rules cover the shape of a predicate … and not its references

tooling 标 gate/脚本本身的改动。

⭐ 给接卡人的三条

1. 人口先量，再写规则。 「字段名要对着什么解析」在 lint 里不是自明的——它需要拿到对象的字段集。⛔ 动手前先确认 @objectstack/lint 在这条规则的输入层里拿得到对象定义（authoring-rule-input-tier 那套分层是相关的）。若拿不到，这条规则的可行形状就变了，请回 pm:retriage 而不是硬做。
2. current_user.* 的合法集合要从一个来源取。 卡给了 hotcrm 自己的守卫列出的五个（id / organization_id / positions / org_user_ids / email），⚠️ 但那是下游仓的清单。⛔ 不要把它抄进 packages/lint——先在平台侧找到那个预解析集合的权威定义；找不到就说明平台没有声明它，那本身是一个更上游的 finding，请单独报而不是在 lint 里硬编码一份。
3. ⛔ 不要顺手把 hotcrm 的两条本地断言退掉。 卡说得很清楚：objectstack-ai/hotcrm#1625 已判定两侧互不包含（平台的 rls-predicate-unparseable 会在本地 sweep 接受的形状上起火），所以两条断言被保留。本卡落地后请重新评估一次，⛔ 但那是 hotcrm 的决定，不是本卡的。

相邻卡

卡指出这与 #16108 是「同一个字段存在性不对称，隔一个面」（那边是 security-fls-unqualified-key：未限定的键会报、限定但悬空的键静默）。⇒ 两张同族。⛔ 不合并（不同规则、不同文件），但接卡时值得同批做——引用解析这件事只想一次比想两次便宜。#16108 本轮也在我的裸卡队列里。

---

Generated by Claude Code