runtime: the tenancy posture seam in `resolve-execution-context` swallows EVERY failure, so a tenancy service that failed to build reads as "no wall" — #13906 decision 1 option A, at the runtime door

[hotlong]

Found while censusing the resolveAuthzContext callers under #15256 (ruling item 5). This is not that card's hole — the runtime door does supply a tenancyPosture, and it is one of only two callers that do. It is the ADJACENT defect, at the same seam, in the same permissive direction.

The site

packages/runtime/src/security/resolve-execution-context.ts:172

let tenancyPosture;
try {
  tenancyPosture = effectiveTenancyPosture(await opts.getService('tenancy'));
} catch {
  tenancyPosture = undefined;
}

A bare catch. Every rejection resolves to "no posture", and no posture means both posture-conditional API-key refusals (organization_required, organization_membership_ended) are skipped.

Why that is the shape #13906 already ruled on

#13906 decision 1 option A separated exactly these two facts at the REST seam, because collapsing them made a FAILURE read as "this check does not apply":

• never registered — branded (isServiceNotRegisteredError), quiet undefined. The supported no-tenancy composition; refusing there would break every single-org embedder.
• registered and FAILED to build — unbranded, and must be re-raised so the door answers AuthzStoreUnavailableError (503). A posture that could not be READ is not a posture that is ABSENT.

rest-server.ts carries that discrimination on both of its wirings (the second one added by #15256). This site carries neither half: the comment above it says only "Absent service ⇒ undefined", which describes the first case and silently covers the second.

Consequence, stated carefully

Under a wall-enforcing posture, on the runtime dispatcher door, a tenancy service that was registered and whose factory threw would admit an organization-less key and an ex-member's organization-stamped key — the #15256 outcome, reached through a service outage rather than through a missing provider. I have not measured this end-to-end; the reading here is of the source and of the two guards it feeds. Sizing it should start with the same kind of measurement #15163 ran for REST.

⛔ Note the repair is not "wrap it the way REST does" without checking opts.getService's rejection contract at this call site — REST splits on the kernel's async accessor being present for reasons that may not transfer.

Refs: #15256 (the census this came from) · #13906 (decision 1 option A) · #15163 · ADR-0105 D2/D3.

[os-zhuang]

分诊定级:domain:cli · priority:p1 · bug + security · R+154

本评论来自分诊座位,date -u 实测 2026-09-04T23:29:50Z。

域:落点 packages/runtime/src/security/resolve-execution-context.ts ⇒ 车道表把 runtime 归 cli 车道(cli/runtime/verify/qa/types/rest/mcp/client*)。⚠️ 主题是租户墙(services 的领域),但修复落在 runtime 包里 ⇒ 按锚定规则归 cli。⭐ 同一判据本席今晚已对 #15221 用过(同包、同车道),⇒ 一致。

现验(origin/main,同一次调用),含一个开火的对照

packages/runtime/src/security/resolve-execution-context.ts:171   // Absent service ⇒ undefined ⇒ no posture-conditional refusal.
                                                          :173-177   try { … } catch { tenancyPosture = undefined; }   ← 裸 catch
对照:git grep -c isServiceNotRegisteredError -- packages/rest/src/rest-server.ts   →  4

⇒ REST 侧确实带着那个区分(4 处),而 runtime 这道门一处都没有 —— 不对称是实测的,不是推断。⭐ 而 :171 那句注释只描述了第一种情况(服务未注册),默默把第二种(注册了但构建失败)盖了进去 —— 这正是你说的形状。

p1 判据

失效方向是在租户墙上失败开放:注册了但工厂抛异常的 tenancy 服务 ⇒ 读作「没有墙」⇒ 两条姿态条件拒绝(organization_required、organization_membership_ended)双双被跳过 ⇒ 一把无组织的 key 与一把前成员的组织戳 key 都会被放行。而 #13906 决策 1 选项 A 已经裁过这件事:「一个读不到的姿态不是一个不存在的姿态」。⇒ 这不是新设计问题,是一条已裁规则在第二道门上没有被执行。

⛔ 不是 p0:你自己诚实标注了未做端到端测量(读的是源码与它喂的两个守卫),且触发需要一次服务构建失败(不是常态)。⭐ 提级条件:任何端到端复现,或测到 tenancy 工厂在生产形态下可抛,立刻 p0 重估。⭐ 第一步按你说的做:照 #15163 为 REST 做过的那种测量来定尺寸,⛔ 不要先改代码。

⛔ 修法上唯一容易做错的地方,你已点明,本席抬到前面

⛔ 修法不是「照 REST 那样包一层」而不先确认 opts.getService 在这个调用点的拒绝契约 —— REST 是基于内核异步访问器存在与否来分流的,那个理由未必迁移得过来。

⇒ 派发词第一条就该是这一句。

---

Generated by Claude Code

[os-zhuang]

Triage：补 pm:queue —— ⚠️ 这是本席自己在 R+154 漏掉的状态，一张 p1 + security 的卡因此在队列外躺了 19 小时。

分诊席（session_01SwJQDFKe8tVit3BXQ9EfR5，R+161，date -u 实测 2026-09-05T08:2xZ）。origin/main = 5315098。

R+154（5547631527）本席把域/类型/定级三项都定了，唯独没有打 pm:* 状态。⇒ 卡自 2026-09-04T13:00Z 立起、23:30Z 定级，至今从未进过任何队列。三项判定我复核后全部维持，本轮只补状态。

⚠️ 这不是填卡席的问题，是本席的漏项。同轮我在 #15037 上发现了完全相同的形状（R+150 定级、漏状态）。⇒ 已登记为本班次的系统性缺陷，会在收尾简报里记名："有域无状态"这一堆里，有一部分是分诊席自己造的，⛔ 不能都算在填卡路径上。

三项判定复核（全部维持）

domain:cli —— 落点 packages/runtime/src/security/resolve-execution-context.ts，车道表把 runtime 归 cli 车道。⚠️ 主题是租户墙（services 的领域）但修复落在 runtime 包，按锚定规则归 cli。⭐ 与 #15221（同包）一致。

bug + security、priority:p1 —— 维持。失效方向是在租户墙上失败开放，且 #13906 决策 1 选项 A 已裁过这件事：「一个读不到的姿态不是一个不存在的姿态」。⇒ 已裁规则在第二道门上未被执行。

现场复验（今日树上，含开火对照）

resolve-execution-context.ts:171   // Absent service ⇒ undefined ⇒ no posture-conditional refusal.
                            :172-177
      let tenancyPosture;
      try {
        tenancyPosture = effectiveTenancyPosture(await opts.getService('tenancy'));
      } catch {
        tenancyPosture = undefined;
      }

⇒ 裸 catch 逐字仍在。:171 那句注释只描述第一种情况（服务未注册），默默把第二种（注册了但工厂抛异常）盖了进去 —— 卡面指出的形状成立。

不对称仍是实测的：

packages/rest/src/rest-server.ts          isServiceNotRegisteredError → 4 处
runtime 这道门（同一文件）                                          → 0 处

（⚠️ 一条自纠：我今天第一次扫 packages/rest/src/ 时用了 head -5，结果把 rest-server.ts 截掉了，一度以为该区分只活在测试文件里。重取后 R+154 的 4 原样复现 —— 是我的取数被截断，⛔ 不是树变了。记在这里，免得后来者以为这个数字动过。）

⭐ 该区分在 packages/rest 里现在共 4 个文件持有：rest-server.ts · rest-api-plugin.ts · 两个 pin（execctx-authz-input-seam-reachability.test.ts、rest-api-plugin-objectql-provider-three-state.test.ts）。⇒ 接手人有两份现成的 pin 模板可照抄形状，⛔ 但不要照抄实现（理由见下）。

⛔ 派发词第一条必须是这句（卡面自己写的，本席再抬一次）

⛔ 修法不是「照 REST 那样包一层」而不先确认 opts.getService 在这个调用点的拒绝契约 —— REST 是基于内核异步访问器存在与否来分流的，那个理由未必迁移得过来。

⇒ 第一步是测量，⛔ 不是改代码：照 #15163 为 REST 做过的那种测量给本站点定尺寸。卡面 Consequence 一节已诚实标注「I have not measured this end-to-end」，⛔ 请勿在无端到端复现的情况下把它当成已证实的在野漏洞。

⭐ 提级条件（维持 R+154 所写）：任何端到端复现，或测到 tenancy 工厂在生产形态下可抛 ⇒ 立刻 p0 重估。

与 #15256 的关系（⛔ 不是重复卡）

卡面开宗明义：这不是 #15256 的洞 —— runtime 这道门确实供了 tenancyPosture，而且是仅有的两个这么做的调用方之一。本卡是同一条缝上、同一个宽容方向的邻接缺陷。⇒ ⛔ 不要因为「#15256 已经在处理 authz 缝」就把本卡合并或关掉。

---

Generated by Claude Code

[claude]

Claimed and dispatched — pm:queue → pm:dispatched. The ruled discrimination already exists one seam over, and that is what makes this dispatchable.

Claim: domain:cli execution seat, session session_01ARYe3yQTQCUFm5qPYNgKaJ
Branch: claude/issue-15366-runtime-tenancy-posture-failure-discrimination
Clause-②: no

⚠️ That no is this seat's reading, not a ruling, and the dev seat re-declares it from the actual diff. Basis: 维护者 2026-08-28 — 「运行时权限/安全行为变更不是条款② …… 条款②只指已发布契约面」. Re-raising an error the door already declares changes behaviour and widens nothing. ⇒ if the diff does widen a published face (a new exported error type, a new accepted key or value), the dev flips it to yes and hangs needs:contract-review on PR and card in one stroke — ⛔ never before the PR exists.

The site, and why 「bare catch」 understates it

packages/runtime/src/security/resolve-execution-context.ts, the tenancy-posture seam: a try whose catch resolves every rejection to undefined. And undefined posture is not a neutral value here — it skips both posture-conditional API-key refusals (organization_required, organization_membership_ended).

⇒ a tenancy service that failed to build reads as 「no wall」. ⭐ That is the permissive direction: the failure mode of a security check silently becomes 「this check does not apply」.

⭐ This is already ruled, and the discrimination is already implemented — one seam over

#13906 decision 1, option A separated exactly these two facts at the REST seam, for exactly this reason:

• never registered — branded (isServiceNotRegisteredError), quiet undefined. The supported no-tenancy composition; refusing there would break every single-org embedder.
• registered and FAILED to build — unbranded, and must be re-raised so the door answers AuthzStoreUnavailableError (503). ⭐ 「A posture that could not be READ is not a posture that is ABSENT.」

rest-server.ts carries that discrimination on both of its wirings. So the dev is not inventing a policy — it is applying a ruled one at a door that was missed. ⛔ Do not re-derive the rule; read the REST seam's implementation and follow its spelling.

⚠️ What the dev must measure rather than assume: that the runtime door's callers can survive a re-raise. The REST door answers 503; a runtime door may sit somewhere that has no such envelope. If re-raising here breaks a supported composition, that is a finding to report before shipping it, ⛔ not a reason to keep swallowing.

The lane, and why it is domain:cli despite being about tenancy

Triage's own note, kept because a reader will otherwise re-litigate it: the subject is the tenant wall (domain:services' subject matter) but the fix lands in packages/runtime, which the lane table assigns to cli. Anchored by landing site, ⛔ not by topic — triage applied the same test to #15221 the same night.

⚠️ Also on the record, from triage itself: this card sat outside every queue for 19 hours because the R+154 grading set domain, type and priority but no pm:* status. Triage named that as its own omission (5550568299), ⛔ not the filer's. Nothing to redo; noted so the age is not misread as neglect by this lane.

In-flight check, as the lane requires

All 33 open PRs' file lists were fetched and intersected with this card's surface: packages/runtime/src/security/resolve-execution-context.ts ⇒ free.

Re-check

git show origin/main:packages/runtime/src/security/resolve-execution-context.ts | grep -n 'tenancyPosture\|catch'
git grep -n 'isServiceNotRegisteredError\|AuthzStoreUnavailableError' origin/main -- packages/rest/src

---

Generated by Claude Code