发现于 #4984 的实现过程(那一单只修 sharing-rule 那段,这条按 Prime Directive #10 单独记账,未随 PR 一起改)。
事实
packages/lint/src/validate-org-axis-red-lines.ts 的 ADR-0105 D6 ① 有三段扫描:
permissions[].rowLevelSecurity[].using/check —— 键正确(PermissionSetSchema.rowLevelSecurity,RLS_POLICY_KEYS 含 using/check);objects[].rowLevelSecurity ?? objects[].rls —— ObjectSchema 根本不声明 rowLevelSecuritysharingRules[] —— validateOrgAxisRedLines 读的 sharing-rule 键是 spec 拒收的:ADR-0105 D6 ① 在 criteria 路径上从不触发 #4984
实测(build 后的 spec):
ObjectStackSchema.safeParse({
name: 'x', version: '1.0.0',
objects: [{ name: 'work_order', label: 'WO', fields: { n: { type: 'text', label: 'N' } },
rowLevelSecurity: [{ name: 'r', using: "parent_organization_id = 'x'" }] }],
})
=> REJECTED: objects.0: Unrecognized key(s) on this object: `rowLevelSecurity`.
packages/spec/src 里 rowLevelSecurity 只出现在 security/permission.zod.ts(permission set 的键)和 conversions/registry.ts(permission.rowLevelSecurity.priority 的退役转换),没有任何 hoist / normalize 把 objects[].rowLevelSecurity 搬到 permissions[]。
后果
规则注册为 input: 'parsed',所以在 os validate / os build 上第 2 段扫描恒空 —— 与 #4984 同一缺陷类(consumer 读了 producer 不声明的键)。只有 os lint(不 parse,退回 normalized)那一层还能看见作者手写的 objects[].rowLevelSecurity,而那种写法本来就会被 spec parse 拒收。
危害小于 #4984 (第 1 段覆盖了 RLS 的唯一可授权落点,所以红线本身没有洞),但那段代码 + 它的测试 fixture 描述了一个不存在的授权面,读代码的人会以为对象上可以直接写 RLS 策略。
待定的是「往哪边修」,所以没有顺手改
两种方向,取舍不同:
A. 删掉第 2 段 —— 承认 RLS 策略只挂在 permission set 上。最小、诚实,但如果将来要给 object 加 RLS 授权面,这段还得回来。B. 给 ObjectSchema 加 rowLevelSecurity —— 让代码描述的授权面真的存在。这是 spec 公共契约的扩张,要先回答「对象级 RLS 与 permission-set 级 RLS 如何合并/优先」,属于 ADR 级决定。
倾向 A(ADR-0049 enforce-or-remove:声明了没人兑现的东西就该退役;真要 B 也应该由一份 ADR 驱动而不是由一段 lint 代码倒逼)。请维护者定夺。
同时:validate-org-axis-red-lines.test.ts 里对应的两个 fixture(objects[0].rowLevelSecurity[...])不是 spec 合法形状。#4984 加的 fixture/schema 漂移守卫(sharingRule() / objectFixture())因此没有 覆盖它们 —— 修这条时应一并纳入守卫。
相关:#4984 、#4698 、ADR-0105 D6、ADR-0049。
发现于 #4984 的实现过程(那一单只修 sharing-rule 那段,这条按 Prime Directive #10 单独记账,未随 PR 一起改)。
事实
packages/lint/src/validate-org-axis-red-lines.ts的 ADR-0105 D6 ① 有三段扫描:permissions[].rowLevelSecurity[].using/check—— 键正确(PermissionSetSchema.rowLevelSecurity,RLS_POLICY_KEYS含using/check);objects[].rowLevelSecurity ?? objects[].rls——ObjectSchema根本不声明rowLevelSecurity;sharingRules[]—— validateOrgAxisRedLines 读的 sharing-rule 键是 spec 拒收的:ADR-0105 D6 ① 在 criteria 路径上从不触发 #4984 修的那段。实测(build 后的 spec):
packages/spec/src里rowLevelSecurity只出现在security/permission.zod.ts(permission set 的键)和conversions/registry.ts(permission.rowLevelSecurity.priority的退役转换),没有任何 hoist / normalize 把objects[].rowLevelSecurity搬到permissions[]。后果
规则注册为
input: 'parsed',所以在os validate/os build上第 2 段扫描恒空 —— 与 #4984 同一缺陷类(consumer 读了 producer 不声明的键)。只有os lint(不 parse,退回 normalized)那一层还能看见作者手写的objects[].rowLevelSecurity,而那种写法本来就会被 spec parse 拒收。危害小于 #4984(第 1 段覆盖了 RLS 的唯一可授权落点,所以红线本身没有洞),但那段代码 + 它的测试 fixture 描述了一个不存在的授权面,读代码的人会以为对象上可以直接写 RLS 策略。
待定的是「往哪边修」,所以没有顺手改
两种方向,取舍不同:
ObjectSchema加rowLevelSecurity—— 让代码描述的授权面真的存在。这是 spec 公共契约的扩张,要先回答「对象级 RLS 与 permission-set 级 RLS 如何合并/优先」,属于 ADR 级决定。倾向 A(ADR-0049 enforce-or-remove:声明了没人兑现的东西就该退役;真要 B 也应该由一份 ADR 驱动而不是由一段 lint 代码倒逼)。请维护者定夺。
同时:
validate-org-axis-red-lines.test.ts里对应的两个 fixture(objects[0].rowLevelSecurity[...])不是 spec 合法形状。#4984 加的 fixture/schema 漂移守卫(sharingRule()/objectFixture())因此没有覆盖它们 —— 修这条时应一并纳入守卫。相关:#4984、#4698、ADR-0105 D6、ADR-0049。