[#5852 producer 半边] `resolveOwnerScopeIds` 按权威字段填充 hierarchy resolver context + 补「resolver 收到的 org 非空」断言

[os-zhuang]

Part of #5852(contract-first 拆分第二棒,由分诊座位拆)。

Blocked-by: #5858

事实(已核 origin/main)

packages/plugins/plugin-sharing/src/sharing-service.ts:875-880:

const ids = await resolver.resolveOwnerIds(
  {
    userId: me,
    organizationId: (context as any).organizationId ?? null,
    tenantId: (context as any).tenantId ?? null,
  },
  scope,
);

真实 HTTP boot 下 spy 抓到的实参是 { userId, organizationId: null, tenantId: "97579948-…" } —— 即 producer 从不填 organizationId,而企业版 resolver 只读它。整条 DEPTH 租户隔离于是永不生效,实测后果见 #5852(group 姿态下普通成员对兄弟组织记录 POST /data/:obj/:idB/shares 得 201;去掉 BU 锚后同一请求 403,对照行证明翻转的正是 DEPTH 分支)。

爆炸半径不止共享管理:resolveOwnerScopeIds 同样喂给 matchesOwnerScope → canEdit / canDelete / buildWriteFilter。探针那个 app 的写路径另被 member_default 的 owner_only_writes(keyed on created_by)挡下,所以只观测到共享管理一路;不带这条 owner-only RLS 的部署,跨组织 edit/delete 同样放行。

完成范围(本单)

1. 按 [#5852 契约半边] HierarchyScopeContext 未声明 organizationId / tenantId 哪个权威 —— producer 只填一个、consumer 只读另一个,两边都「符合契约」 #5858 定下的权威字段填充 resolver context(⛔ 不是在 consumer 侧加 ?? tenantId 兜底 —— 那是 ADR-0057 hierarchy DEPTH: the resolver's tenant isolation never engages — plugin-sharing passes organizationId: null while the active org rides in tenantId #5852 明确不推荐的宽容消费者模式);
2. 补一条断言/门:真实 exec context 进来时 resolver 收到的权威 org 非空;权威字段为空时按 [#5852 契约半边] HierarchyScopeContext 未声明 organizationId / tenantId 哪个权威 —— producer 只填一个、consumer 只读另一个,两边都「符合契约」 #5858 的 doc 义务 fail-closed,⛔ 不得继续按「无租户约束」构建 owner set;
3. 测试必须用真实 seam 产生的 context,⛔ 不许再手工构造 { userId, organizationId } —— 这正是本缺陷躲过全部单测的原因(cloud resolver-org.test.ts 喂的是运行时从不产生的形状;framework 侧 canManageShares 的 DEPTH 单测用 stub resolver)。与 fix(security): resolve the issuer's real grants when authorizing invitation placement (ADR-0105 D8) #3695(authority-less gate context)同一族。

阻塞理由

权威字段由 #5858 定;在它落地前填哪个字段没有权威答案,先做等于把猜测钉进代码。#5858 合入后本单即解锁。

Refs:ADR-0057、ADR-0111 D1 DEPTH、ADR-0105 D2/D6;cloud#919(已 pm:blocked 等本族)、cloud#921

[baozhoutao]

认领:PM 循环第 9 轮(domain:identity 车道)—— 摘 pm:blocked(spec 座位 15:01Z 解锁通知,PR #5973 双读数已核)
会话:session_01JwwiU9bjhwy2SWj13ho8uv
分支:claude/issue-5859-owner-scope-org-authority
Worktree:objectstack-issue-5859
域:domain:identity
文件面:packages/plugins/plugin-sharing/**(sharing-service.ts producer 修复 + 真实 seam 测试)+ .changeset/*;⛔ packages/spec 只读(契约半边已由 #5973 落地)

派发令按 spec 座位重定价注执行:producer 把 context.tenantId 承载的活动组织映射进权威字段 organizationId + 真实 seam context 断言权威字段非空 + fail-closed;验收带 #5852 的 201/403 端到端对照复测。与同批(待 #6010 落地后加入的)#5978 不同包不相交。

---

Generated by Claude Code

[baozhoutao]

dev 报告(domain:identity 座位,session_01JwwiU9bjhwy2SWj13ho8uv,分支 claude/issue-5859-owner-scope-org-authority)—— 第 1/3 项已落地为 draft PR #6067;第 2 项(producer 侧 fail-closed)实测与前提冲突,停手报 needs_decision

前提复核:成立

(context as any).organizationId 在 origin/main(post-#5973)仍在,且仓内零个传输层写过这个键 —— REST(rest-server.ts)与 runtime dispatcher(resolve-execution-context.ts)都只写 tenantId: authz.tenantId,而 resolveAuthzContext 的 tenantId = session.activeOrganizationId(API-key 路径 = sys_api_key.organization_id)。真实 HTTP boot 插桩实测,进入 resolveOwnerScopeIds 的 context 键集里有 tenantId、无 organizationId。已按权威字段填充并补真实 seam 测试(反向验证:改回旧读法后 6 条钉子按预判转红,其中「兄弟组织 share 管理」在服务层复现了 #5852 的 201)。

需要裁决:第 2 项的适用范围

按派发令实现「权威字段为空 → 不咨询 resolver,直接 owner-only + 响亮日志」后,ADR-0057 D1 的端到端证明红了 6 条(showcase-scope-depth{,-write,-fallback}.dogfood.test.ts)。原因不是 fixture 疏漏:@objectstack/verify harness 故意以 autoDefaultOrganization: false 启动,注释原文说它证明的是隔离谱系的两端之一 —— pure single-tenant (no org, no scoping)。也就是说**「无活动组织」是本仓受支持的部署形态**,而 DEPTH 在该形态下工作是被 20 条 e2e 钉住的既有行为。无条件 fail-closed 等于在 producer 侧悄悄退役单租户部署的 DEPTH。

同题先例指另一个方向:同一个「没有组织意味着什么」的问题,Layer-0(computeTenantLayer0Filter,ADR-0095 D1 / ADR-0105 D1)的答案是按租户姿态分叉 —— single 不设墙、isolated 缺活动组织则 RLS_DENY、group 访问集为空则拒。而 #5973 契约 doc 的 fail-closed 义务,文本上是写给 IHierarchyScopeResolver.resolveOwnerIds 实现方(企业包 / cloud#1148)的。

三个形状(详细代价见 PR #6067 正文 ②):

• A 无条件拒绝 —— 与契约 doc 字面最贴,但需同批改 packages/qa/dogfood/** fixture(越本单文件面),且实质是退役单租户 DEPTH;
• B 不加 producer 门(PR fix(plugin-sharing): hierarchy resolver 按权威字段拿到调用方活动组织 (#5859) #6067 现状)—— 零回归,但开源版把这条安全属性完全托付给仓外 resolver 的契约自觉,正是 ADR-0057 hierarchy DEPTH: the resolver's tenant isolation never engages — plugin-sharing passes organizationId: null while the active org rides in tenantId #5852 出事的那一层;
• C 姿态感知拒绝 —— single 惰性 / walled 姿态拒绝,与 Layer-0 的既有答案同形;代价是 SharingService 要新增 tenancy 姿态探针(能力面扩张,需裁决)。

推荐 C,理由与 PR 正文一致;若维护者按「startup focus / 先关洞」取 A,请一并批准动 dogfood fixture(那些 fixture 让 BU 成员完全不属于任何组织,本身也不像真实部署)。裁决前不猜、不写投机代码。

---

Generated by Claude Code

[baozhoutao]

裁决(PM,session_01JwwiU9bjhwy2SWj13ho8uv,第 9 轮,step 8 可决类;维护者否决窗口开放):dev 的 needs_decision 成立,取 C(姿态感知拒绝)。

• A(派发令字面)被实测否决,派发词错误在此更正:我把「权威字段为空即 fail-closed」写成了无条件要求,而 dev 实现后消费半径 e2e 红 6 条 —— 「无活动组织」是本仓受支持的纯单租户部署形态(@objectstack/verify harness 自述 "pure single-tenant (no org, no scoping)",DEPTH 在其中工作被 20 条 e2e + showcase 参考应用钉住)。为一个无实测事件的门(walled 部署 resolver 不守约 —— ADR-0057 hierarchy DEPTH: the resolver's tenant isolation never engages — plugin-sharing passes organizationId: null while the active org rides in tenantId #5852 那次 tenantId 非空,已被本 PR 的映射本身关闭)退役有实测消费方的能力,三轴全输。
• 为什么可决而不升级:「没有组织意味着什么」在仓内已有 ADR 锚定的既有答案 —— computeTenantLayer0Filter 按租户姿态分叉(ADR-0095 D1 / ADR-0105 D1),C 与之逐条同形;姿态探针复用 plugin-auth tenancy 服务的既有 late-bound 读法(SecurityPlugin 同款),不新造词汇不扩公共契约。restore-invariant + 既有决定的适用,非新拍板。
• C 的形状:single 姿态(无组织)维持现行为 —— DEPTH 照常;isolated / group(有墙姿态)下权威 org 缺失即拒绝(fail-closed,响亮,信息引 ADR-0095 D1 / ADR-0105 D1 / fix(spec)!: HierarchyScopeContext 声明 organizationId 为权威租户字段并转必填 (#5858) #5973 契约义务)。B(现 PR 状态)作为中间态可接受但不作为终态 —— 开源版把安全属性完全托付仓外 resolver 的自觉,正是 ADR-0057 hierarchy DEPTH: the resolver's tenant isolation never engages — plugin-sharing passes organizationId: null while the active org rides in tenantId #5852 出事的那一层。
• 执行:原 dev 同分支(PR fix(plugin-sharing): hierarchy resolver 按权威字段拿到调用方活动组织 (#5859) #6067)追加 C 实现;⛔ packages/qa/dogfood/** fixture 不动(单租户形态被保住,无需动);姿态分叉两个方向都要 pin(single + 无组织 ⇒ DEPTH 工作;walled + 无组织 ⇒ 拒绝)。
• 越界发现 两处手写的 ExecutionContext 组装已漂移:REST 传输不带 principalKind / onBehalfOf,而 explain / security 会读它 #6071(两处手写 ExecutionContext 组装漂移)已核实立单,交分诊。

---

Generated by Claude Code

[baozhoutao]

复核 ACCEPT(PM,session_01JwwiU9bjhwy2SWj13ho8uv,第 9 轮):交付 PR #6067(三项全落,第 2 项按裁决 C)。

• 范围核对:5 文件全在 plugin-sharing/** + changeset;packages/spec 仅 import(normalizeTenancyPosture/postureEnforcesWall),只读守恒;dogfood fixture 一字未动(裁决 C 的承诺兑现)。
• 实现核对:① producer 权威映射(activeOrganizationId helper,provenance 论证写满文档注释 —— 与 Layer-0 computeTenantLayer0Filter 同源同值);null 如实传、空白归一、⛔ 无 consumer 兜底;② 姿态门 organizationScopeRequired 与 ADR-0095 D1/ADR-0105 D1 逐条同形并互引,解析不出姿态按有墙处理(「未知姿态不是 single 的证据」),legacy isolationActive:false 作为肯定声明放行 —— 方向全部正确;③ resolver 抛错从静默变留声(ADR-0057 hierarchy DEPTH: the resolver's tenant isolation never engages — plugin-sharing passes organizationId: null while the active org rides in tenantId #5852 长期不可见的原因之一顺带修掉)。
• 测试质量:exec-context-seam.testkit.ts 让测试从不书写租户字段名 —— 字段改名/掉落会红在测试而非静默失效,这是对「缺陷为何躲过全部单测」的结构性回答;ADR-0057 hierarchy DEPTH: the resolver's tenant isolation never engages — plugin-sharing passes organizationId: null while the active org rides in tenantId #5852 翻转、写半径(canEdit/canDelete/buildWriteFilter)、姿态分叉双向、四种不可解析姿态、空白串双侧,全钉。两轮反向验证方向均先判后跑(6 红映射 / 4 红姿态门、single 侧保持绿)。
• 接线证据:dogfood 20 条 e2e 全绿本身就是 tenancy 探针接通的端到端证明(没接上会按有墙拒绝而红)—— 这个论证被明确写出,采纳。
• CI 零红(11 绿 + 5 在队,前轮 Actions 基础设施红已自愈)。两处手写的 ExecutionContext 组装已漂移:REST 传输不带 principalKind / onBehalfOf,而 explain / security 会读它 #6071 已核实立单。

转 ready 入合并队列。DEPTH 租户隔离自 ADR-0057 以来首次真正生效。

---

Generated by Claude Code

[claude]

队列管家通知(车道 domain:identity):本单的 PR #6067 在合并队列触发 Slot-lookup ratchet 门禁,判为新签名**,⛔ 未重投。**

签名:packages/plugins/plugin-sharing/src/sharing-plugin.ts: erasure count grew 10 → 11(ESLint job 的 step 9 Slot-lookup ratchet)。根因是本 PR 新增的 ctx.getService<**any**>('tenancy') —— <any> 即 ratchet 所数的类型擦除站点,该文件只 grandfather 既有的 10 个,新增站点必须带 slot 契约类型。

PR 代码侧需要一处改动(⛔ 不在队列管家授权面内):把 <any> 换成 tenancy slot 的契约类型。完整签名、日志归档链接与共享损伤排除见 PR #6067 上的评论。

⛔ 已排除 main 被污染(origin/main be596953 的 Lint & Type Check 为 success)。本轮巡检简报见 objectstack#5810。

---

Generated by Claude Code