Repository navigation
ADR-0105 D6 ② 只拦 business_unit 收件人,漏了 unit_and_subordinates —— 同一个跨 org BU 授权,更宽的那个反而放行 #4991
Description
Activity
认领(PM 分派)
- session:
session_018iARDqtrhQgz6fVHDeDkbQ - 分支:
claude/issue-4991-d6-unit-and-subordinates - 车道:
domain:devx(落点packages/lint/src/validate-org-axis-red-lines.ts,fix(lint): org-axis 红线读 spec 声明的 sharing-rule 键 —— ADR-0105 D6 两条门禁此前从不触发 (#4984) #4992 已合入,同文件串行解锁)
要点:D6 ② 现只拦
business_unit,漏了 ADR-0105 D6 ② 原文点名且授权面更大的unit_and_subordinates(整棵 BU 子树)。#4984 的 dev 已预核过按此扩张现有真实元数据不产生新红。
Generated by Claude Code
- session:
审核通过 — PR #5004 已取消草稿并挂上 auto-merge(SQUASH)
词表核对做到了本单要求的深度,且放行清单不是猜的:以
ShareRecipientType五成员枚举为准,拦二放三;放行的user/team/position逐一按expandRecipient的运行时展开路径复核 —— 恰好只有拦的两个走BusinessUnitGraphService,其余各走各的扁平展开。差集在规则注释里表格化,没有留未说明的项。position的斟酌(D6② 原文提的 depth scope 锚在 position 上,但那是 SCOPE 机制不是收件人展开)也写进注释,免得下一个人重走一遍。根因防复发是这单最重要的一笔:新增结构性断言"拦截半 ∪ 放行半 == 枚举全集"。本单本身就是"照着一个收件人写完没回头看枚举"的产物 —— 将来加第六个成员会在词表处判红,而不是无声落进没人裁决过的那一桶。这与 #4835 的词表教训同型,这次直接内建了防线。
运行时契约里那个刻意不可授权的
queue也记了账并指明将来的回归点。真实元数据是独立重跑而非沿用 #4984 的预核(全仓非测试sharedWith只有两个 examples 共 11 条,0 red)。顺带修掉 hint 里指向不存在收件人类型("permission-set audience")的过时措辞,范围正当。落点 3 文件全在
packages/lint,20 → 25 测试全绿。
Generated by Claude Code
- added a commit that references this issue
on Aug 4, 2026 - added a commit that references this issue
on Aug 4, 2026
发现于 #4984 的实现过程(那一单只修被拒别名的读法,这条是覆盖面问题,按 Prime Directive #10 单独记账)。
事实
packages/lint/src/validate-org-axis-red-lines.ts的ORG_AXIS_CROSS_ORG_BU_GRANT(D6 ②)只对一种收件人类型判红:而
ShareRecipientType里有两个业务单元收件人:business_unit—— 正好一个 BU 的成员(无子树);unit_and_subordinates—— 一个 BU 加上其全部后代单元的成员(ADR-0057 D5 子树扩张)。ADR-0105 D6 ② 的原文点名的恰恰是后者:
后果
在
tenancy.enabled: false(或systemFields.tenant: false)的平台级对象上:sharedWith: { type: 'business_unit', value: 'bu_x' }sharedWith: { type: 'unit_and_subordinates', value: 'bu_x' }两者的缺陷完全相同 —— 平台级对象没有 organization 列可供 Layer 0 收口,授权跨到库里每一个 organization —— 而漏掉的那个授权面更大(整棵子树而非单个单元)。规则自己的文档注释也只写了
business_unit,所以这不像是有意的取舍,更像是照着一个收件人写完就没回头看枚举。注:#4984 之前这条规则读的是被拒别名
sharedTo/recipient,所以 ② 对任何 spec 合法的 stack 都从不触发;#4984 修好键名后这个覆盖面缺口才第一次变得可观察。建议
把判定改为收件人类型 ∈
{ business_unit, unit_and_subordinates },并在 message 里保留具体类型名。这是 error 级门禁的扩张,所以没有随 #4984 一起做 —— 需要先确认没有真实元数据踩中。已核查(#4984 分支上):
examples/app-showcase、examples/app-crm的全部 sharing rule 中只有一条unit_and_subordinates(share_new_inquiries_with_field_ops→showcase_inquiry),而showcase_inquiry没有tenancy.enabled: false/systemFields.tenant: false,仓库里也没有任何对象关掉 tenancy —— 因此按上述扩张改完,现有真实元数据不会产生新红。相关:#4984、ADR-0105 D6、ADR-0057 D5。