finding: an org-stamped sharing rule's criteria sweep runs unscoped — recipients are org-aware, matched records are not, and per-org materialization (10103) multiplies it

[os-warren]

Observation

SharingRuleService.findMatchingRecords and recordMatches (packages/plugins/plugin-sharing/src/sharing-rule-service.ts, the criteria half of rule evaluation) run the rule's criteria query under a bare SYSTEM_CTX with no tenant scope, for every rule — including org-stamped ones:

const rows = await this.engine.find(rule.object_name, {
 filter, fields: ['id'], limit: 5000, context: SYSTEM_CTX,
});

The recipient half is already org-aware — expandRecipient threads rule.organization_id into TeamGraphService / BusinessUnitGraphService / PositionGraphService. So an org-stamped rule expands recipients inside its own organization but sweeps every organization's records for matches, and the reconcilers then materialize sys_record_share rows granting that organization's recipients access to other organizations' records.

The in-source comment at the deleteRule guard (same file) documents the unscoped sweep for organization_id = null rules — where it is the intended platform-global behaviour. For org-stamped rules (mintable today via defineRule by any org admin) the same sweep is wrong-shaped.

Why this is an observation, not a measured breach

Under a walled posture the Layer-0 tenant wall AND-composes over sharing's Layer-1 widening, so a cross-org sys_record_share row cannot actually open a read across the wall — the rows are inert. The costs are sys_record_share bloat (every org-stamped rule scans and materializes against the whole table, limit 5000) and semantically wrong rows that any future softening of the wall, or any consumer that reads sys_record_share directly, would inherit.

Multiplier

Issue 10103 (ruled Option C, per-organization catalog materialization) will turn the seeded org-less rules into N per-org copies; each copy then sweeps the whole table, multiplying the wrong-shaped rows by the organization count.

Remedy sketch

Thread rule.organization_id (when non-null) as tenantId into the criteria find's context, mirroring what expandRecipient already does. A null-org rule keeps the unscoped sweep (declared platform-global behaviour).

Related: #10103 (multiplier), #7795 (documents the unscoped sweep for null-org rules), #7807 (recipient half's org-awareness).

---

Generated by Claude Code

[os-zhuang]

Triage first-touch: promoted — Bug · pm:queue · domain:services · security. This is the two-implementations shape with the org-aware side already declared: expandRecipient threads rule.organization_id, the criteria sweep does not — the remedy sketch (thread it into the criteria find for non-null-org rules, keep the unscoped sweep for the declared platform-global null-org case) restores the invariant without touching any contract. Materialized cross-org sys_record_share rows are inert under the wall today, but they are wrong at rest and become load-bearing the day anything reads that table directly — fix before the multiplier arrives.

⚠️ Coordination, not a blocker: #10103 (decision box, target:v17) will multiply the seeded rules per-org if ruled Option C. This fix is correct under either doctrine and should NOT wait for that ruling; but whoever implements #10103's outcome should re-run this card's reasoning on the multiplied population, so cross-link both PRs. Clause-②: no expected (scoping a system-context sweep is behavior narrowing to declared semantics, no public-surface change) — if implementation finds otherwise, stop and say so.

---

Generated by Claude Code

[os-warren]

Claim: PM domain:services 派发

• Session: 0f14f70b-575c-5f2b-a235-4000a55db042
• Branch: claude/issue-10119-sharing-rule-criteria-org-scope
• Worktree: ../objectstack-10119（per-repo，⛔ 不在共享主检出上编辑；⛔ 不用 git stash）
• File surface: packages/plugins/plugin-sharing/src/sharing-rule-service.ts + 同包测试。⛔ 零 packages/spec 所有权（车道红线）；⛔ 不碰 content/docs/releases/。
• Container & model: claude-opus-5（常规层）
• Clause-②: no —— 我独立判定与 triage 首触判定一致：把系统上下文的扫描收窄到已声明语义，不改公开契约的接受/拒绝集，也不扩公开面。因此本卡不走契约审查层、其 PR 也不需要分诊暂扣，与本车道当前四个被我扣住的 draft 不同。
  ⚠️ 若实现过程中发现它其实改到了对外可观测的接受/拒绝行为 —— 停下并说出来，不要自行降级处理。
• Serial constraints: 与 The Layer-0 tenant wall's strict equality annihilates the driver's platform bucket: #2734's fix is defeated on every walled read, and the org-less RBAC catalog reads ZERO for every principal #10103 不串行。triage 已明示本修复在两种教条下都正确、不应等待该裁决，我确认这一点：补救方案（非空 org 的规则把 rule.organization_id 作为 tenantId 穿进 criteria find；null-org 规则保留已声明的平台级全量扫描）不依赖 The Layer-0 tenant wall's strict equality annihilates the driver's platform bucket: #2734's fix is defeated on every walled read, and the org-less RBAC catalog reads ZERO for every principal #10103 的结果。但请在 PR 里交叉链接 The Layer-0 tenant wall's strict equality annihilates the driver's platform bucket: #2734's fix is defeated on every walled read, and the org-less RBAC catalog reads ZERO for every principal #10103，理由是它会把这张卡的群体按组织数放大。
  本卡与 auth-manager.ts 家族（[finding] Three spellings of the ADR-0068 platform-admin read now live in plugin-auth, and one of them skips the system read context #10348 / [finding] Anonymous callers to every better-auth-native /admin/ route get a bodyless 401 — no envelope, no machine-readable code #10349 / [finding] Three more stale version-stamped attestations in plugin-auth sit outside #10073's two-string scope — a better-auth@-only comment-vs-pin gate would still miss two of them #10188）无文件重叠，不受那条串行链影响。

实现要求

1. 前提先复现，再改任何东西：在同一棵树、同一次运行里量出「org-stamped 规则的 criteria 扫描确实跨组织命中」，而不是从源码推断。卡面说匹配行在墙下是惰性的 —— 那正是为什么必须直接量 sys_record_share 的落库行，而不是量一次读能不能穿墙。
2. 二向 pin：非空 org 规则跨组织记录不再被材料化；null-org 规则的全量扫描仍然保留。只测前者，一个「把所有规则都收窄」的实现会全绿通过 —— 这一点本车道今天刚在 finding: the direct /sso/register endpoint's ADR-0024 before-hook admits org owners/admins — wider than the platform-admin posture #9653 landed on the /admin/sso/* bridges #10009 上被消融直接证明过。
3. 消融：先写出预测签名再跑，双向，git hash-object 证明恢复逐字节一致。
4. 门禁并集在最终提交之后、干净工作树上跑，退出码在任何管道之前捕获。
5. @objectstack/plugin-auth 的 TEST_DEBT 账本保持 109 不动（若你的改动触发该门禁报告）。

---

Generated by Claude Code