fix(lint): org-axis 红线读 spec 声明的 sharing-rule 键 —— ADR-0105 D6 两条门禁此前从不触发 (#4984)

[xuyushun441-sys]

Fixes #4984

死态复现(before 证据,最新 main)

validateOrgAxisRedLines 注册为 input: 'parsed',即跑在 Zod parse 之后。它取 rule.criteria ?? rule.filter 与 rule.sharedTo ?? rule.recipient,而 SharingRuleSchema 是 .strict() 的、声明的键是 condition / sharedWith —— 那四个名字只作为被拒别名出现在 sharingRuleUnknownKeyError 里(那是给报错信息用的处方,不是被接受的键)。

在 c87ef7034(本分支的基点)上实测:

=== 1. spec-valid 且违反 D6 ① 的 sharing rule(真实键名) ===
safeParse ok: true
  {"name":"hq_sees_children","object":"work_order","active":true,"accessLevel":"read",
   "sharedWith":{"type":"team","value":"hq"},"type":"criteria",
   "condition":{"dialect":"cel","source":"record.parent_organization_id == 'org_hq'"}}
findings on PARSED stack: []          ← 判绿
findings on RAW (pre-parse) stack: [] ← 判绿

=== 2. 现有测试 fixture 用的死键,过不了 schema ===
name,object,criteria  => REJECTED: Unrecognized key(s) on this sharing rule: `criteria`.
name,object,sharedTo  => REJECTED: Unrecognized key(s) on this sharing rule: `sharedTo`.

=== 3. 平台级对象上的 BU 授权(真实键名,D6 ②) ===
safeParse ok: true
findings: []                          ← 判绿

即:一条声明为 error、以 ADR-0105 D6 红线为依据的门禁,在 sharing-rule 这条路径上对任何 spec 合法的 stack 永不触发;而它自己的测试 fixture 用的正是那些被拒的死键,所以测试全绿、规则全死。

改了什么

1. 规则改读 canonical 键。 rule.condition / rule.sharedWith,不再有 ?? 别名兜底。别名已经在 sharingRuleUnknownKeyError 里有明确处方并被 parse 拒收 —— consumer 不该容忍 producer 契约拒绝的东西(Prime Directive #12)。新增一条测试把这个决定钉住:写 criteria / filter / sharedTo / recipient 的规则不判红,交给 spec 的拒收。

2. 语义按 D6 原文逐条搬,不是只换名字。 别名与真键的形状确实不同:

	死键	真键	形状差异
谓词	criteria / filter	condition	ExpressionInput —— 裸串(作者态)/ { dialect, source }(parse 后)/ { dialect, ast }(compile 后),三种都要能取到文本,新增 expressionText()
收件人	sharedTo / recipient	sharedWith	.strict() 的 { type, value };id 也是被拒别名

expressionText() 刻意不读 meta.rationale —— 那段散文完全可能正当地提到它正在解释「本规则不使用」的那个字段,error 级门禁不能被注释误伤。

path 从笼统的 sharingRules[i] 细化到 sharingRules[i].condition / sharingRules[i].sharedWith,两个槽位各自点名。

3. fixture/schema 漂移守卫(本单的结构性修复)。 只改键名的话,同样的漂移下次还来。现在每个 sharing-rule fixture 都过 sharingRule(),它先用真的 SharingRuleSchema parse 再交给 lint;object fixture 同理走 objectFixture() → ObjectSchema。fixture 一旦与 spec 漂移就在 fixture 处判红,而不是去测一个作者写不出来的形状。元测试本身也自证不死:把 #4984 之前的两个 fixture 原样喂进去,断言它们抛错。

反向验证

场景	结果
真实键名的违规 stack(修复后)	判红并点名 sharingRules[0].condition / .sharedWith
合法 stack(membership / BU / 非 BU 收件人)	判绿
把规则改回读死键,跑新测试	7 failed —— 元测试与行为测试同时判红

改回死键时的失败清单:

× flags a spec-valid sharing rule whose `condition` walks the org parent
× flags the pre-parse `condition` shape too (`os lint` runs on the normalized stack)
× flags the compiled `{ dialect, ast }` condition shape
× flags a recipient that reaches for the org parent
× does NOT resurrect the schema-rejected aliases — parse is that gate
× flags a business-unit grant on a `tenancy.enabled: false` object
× flags the `systemFields.tenant: false` spelling of the same opt-out
 Tests  7 failed | 11 passed (18)

真实元数据上是否有新红

没有。 D6 是 error 级,所以逐条核过:

• examples/app-showcase / examples/app-crm 的全部 sharing rule:没有任何 condition 或 sharedWith 提到 parent_organization_id;
• 全仓没有对象声明 tenancy.enabled: false 或 systemFields.tenant: false,所以 D6 ② 也无处触发;
• default-permission-sets.ts 与 examples/app-showcase/src/security/permission-sets.ts 的 RLS using/check:只有 assignee == current_user.email / owner == current_user.email 一类,无 org 轴引用。

验证

$ pnpm --filter @objectstack/lint test
 Test Files  54 passed (54)
      Tests  987 passed | 4 skipped (991)

$ pnpm --filter @objectstack/lint typecheck
(clean)

$ npx eslint packages/lint/src/validate-org-axis-red-lines{,.test}.ts --no-inline-config
(clean)

顺手发现,已单独建单(未随本 PR 修)

• validateOrgAxisRedLines 的 objects[].rowLevelSecurity 分支同样是死路径:ObjectSchema 不声明该键 #4989 —— 同一文件的 objects[].rowLevelSecurity 分支也是死路径:ObjectSchema 根本不声明 rowLevelSecurity,objects[0] 带该键的 stack 被 parse 拒收。危害小于本单(permission-set 那段覆盖了 RLS 的唯一可授权落点,红线没有洞),但「删掉该段」还是「给 spec 加对象级 RLS 授权面」是 ADR 级取舍,不宜在本 PR 里替维护者决定。
• ADR-0105 D6 ② 只拦 business_unit 收件人,漏了 unit_and_subordinates —— 同一个跨 org BU 授权,更宽的那个反而放行 #4991 —— D6 ② 只拦 business_unit 收件人,漏了 unit_and_subordinates,而 ADR-0105 D6 ② 原文点名的正是后者,且它的授权面更大(整棵 BU 子树)。这是 error 级门禁的扩张,不随本单做;已核查按此扩张现有真实元数据不会产生新红。

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
objectstack	Ignored		Aug 3, 2026 6:57pm

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/lint.

3 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:

• content/docs/automation/hook-bodies.mdx (via @objectstack/lint)
• content/docs/permissions/authorization.mdx (via @objectstack/lint)
• content/docs/releases/v17.mdx (via @objectstack/lint)

Advisory only. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs origin/main → pass the list as args.docs.