两处手写的 ExecutionContext 组装已漂移:REST 传输不带 `principalKind` / `onBehalfOf`,而 explain / security 会读它

[baozhoutao]

来源:#5859(producer 半边)实施时的越界发现,未在该 PR 修复。

事实(已核 origin/main)

resolveAuthzContext(@objectstack/core)被提取出来正是为了让两个 HTTP 入口不再漂移。
但从授权信封组装成 ExecutionContext 的那一步仍是两份手写副本:

• packages/runtime/src/security/resolve-execution-context.ts(dispatcher / MCP 入口)
• packages/rest/src/rest-server.ts(execCtx = { … },os serve / dev 的数据与元数据路由)

两份的字段集已经不一致:runtime 那份按 ADR-0090 D9/D10 设置
ctx.principalKind(human / guest / agent)与 ctx.onBehalfOf,rest-server 那份
完全不设。

消费方是存在的,且在 enforcement 面:

• plugin-security/src/explain-engine.ts:95 — if (!context?.userId || context?.principalKind === 'guest') return 'EXTERNAL';
• plugin-security/src/security-plugin.ts:2557 — const isAgent = context?.principalKind === 'agent';
• observability/src/perf-timing.ts:475 — service / system 的披露闸门
• explain-engine.ts:1122 — explain 输出里回显 principalKind

实测

在 dogfood showcase 全栈 boot(真实登录 + 真实 HTTP 请求)里插桩打印到达
plugin-sharing 的执行上下文,键集为:

userId, tenantId, email, positions, permissions, systemPermissions, posture,
isSystem, org_user_ids, accessible_org_ids, timezone, locale, __kernel, __readScope

__kernel 说明这是 rest-server 那条组装路径;principalKind 不在键集里。

影响面(未评级 — 交分诊)

同一个请求经 dispatcher 与经 REST 会在这两个字段上得到不同上下文,
所以读 principalKind 的判断在 REST 面从不成立(guest 分支、agent 分支)。
是否有用户今天就撞到,取决于这些分支在 REST 面各自还有没有别的等效前置判断
(security-plugin.ts:950 明确写了「按委托 LINK 判断而非 principalKind 标签」,
提示至少 agent 那一路可能另有兜底)—— 请分诊评级,不要按本文的语气推断严重性。

建议方向(非裁决)

把「授权信封 → ExecutionContext」的组装收成一处共享函数(与
resolveAuthzContext 同一 package),两个传输各自只做传输特有的补充
(REST 的 __kernel / authGate,dispatcher 的 OAuth scopes)。#5859 是这一族在
下一跳的活标本:producer 读的 organizationId 是两份组装都没写过的键,
于是整条 DEPTH 租户隔离恒不生效,而两侧看起来都合规。

Refs:#5859、#5852、ADR-0090 D9/D10、ADR-0095 D2

[claude]

分诊(主分诊轮,本轮加扫 —— 本单 16:59Z 立于本轮扫描之后):pm:queue + domain:cli。

域/落点锚定(不按标题词汇猜)

domain:cli。判据是漂移发生在哪一侧:实读 origin/main(9e3709a)——

• packages/runtime/src/security/resolve-execution-context.ts 已合规::190 ctx.principalKind = 'agent'、:191 ctx.onBehalfOf = {...}、:217 'human'、:220 'guest';
• packages/rest/src/rest-server.ts principalKind 零命中(阳性对照:execCtx = { 确在 :2390,故零命中不是路径写错)。

⇒ 要改的是 packages/rest(必改)+ packages/runtime(可能连带),两者按域表同属 domain:cli,单标即可、无需拆跨域。正文建议的「收成一处共享函数、放 resolveAuthzContext 同 package(@objectstack/core ⇒ domain:engine-core)」是方向而非本单范围,见下。

分类理由(为什么入队而不是进决策箱)

ADR-0090 D9/D10 已经是已接受的契约,principalKind / onBehalfOf 该被每个传输带上不是新的产品判断;本单是「声明已在、一个传输没兑现」的 declared ≠ enforced 形状,落点唯一、复现具体(正文有 dogfood 全栈 boot 的插桩键集,__kernel 在、principalKind 不在 —— 该键集自证组装路径是 rest-server 那条)。⇒ 按 restore-invariant 入队,不占维护者收件箱。

消费方核过,并补两条正文没写的

正文列的三处均命中,其中一处行号已漂,另有两处正文未列:

• plugin-security/src/explain-engine.ts:95(与正文一致)
• plugin-security/src/security-plugin.ts — 正文写 :2557,实际在 :2679(const isAgent = context?.principalKind === 'agent')
• packages/runtime/src/action-execution.ts:1025 —— 正文未列,回显 AGENT on behalf of '…'
• packages/observability/src/perf-timing.ts:475 —— ⚠️ 它读的是 'service' / 'system',即枚举不止 human/guest/agent 三值;实施时⛔ 不要按「三值枚举」写穷尽分支或收窄类型。

入队范围钉死(给执行座位,⛔ 越界即停)

1. 在范围内:让 REST 那条组装按 ADR-0090 D9/D10 兑现两个字段,与 runtime 侧同口径。
2. 不在范围内:把两份组装收敛成一处共享函数 —— 那是设计形状(要定 @objectstack/core 的新公开面),按 rule 2 该另立单;若实施中发现不收敛就无法保证同口径,停下上报,不要顺手做成重构。
3. 必答项(验收前必须回答):这次改动会让 REST 面上从未成立过的分支第一次成立(explain-engine.ts:95 的 guest ⇒ EXTERNAL、security-plugin.ts:2679 的 agent 支)。请逐条枚举被激活的判断与其行为差量并钉住;正文自己已给出线索 —— security-plugin.ts:950 明说「按委托 LINK 判断而非 principalKind 标签」,提示 agent 那一路可能另有兜底。若某条激活会产生超出 ADR-0090 D9/D10 声明意图的授权结果变化(尤其 guest 面从宽变严),⛔ 不得径行落地,按 step 8 升 needs-user-decision。
4. ⚠️ rest-server.ts 是全仓最热的共享文件之一([finding] ADR-0076 D11 的第二半从未落地:packages/rest/src/rest-server.ts 已 8593 行(ADR 记录约 5.1k),且无 issue 承接 #5949 记它已 8593 行):认领时申报文件面,并在派发前重查一次在飞 PR —— 本轮核过 31 条 objectstack open PR,当前无任何在飞 PR 触 rest-server.ts / resolve-execution-context.ts / packages/core/src,但这个读数会过期。

查重

三仓 open issue / PR 无影子单。#5859(来源,producer 半边;正文点它为下一跳的活标本 —— organizationId 是两份组装都没写过的键,于是 DEPTH 租户隔离恒不生效)、#5852、#5949(rest-server 体量台账)均为关联而非重复。

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code

[qq9340100]

认领:PM 循环恢复轮(cli 车道,rc.5 后)
会话:session_01Wbxm29qPKnLf44AbSxizqW(GitHub 账号 qq9340100)
分支:claude/issue-6071-rest-execctx-principal-kind
Worktree:objectstack-issue-6071
域:domain:cli
文件面:packages/rest/src/rest-server.ts(:2390 附近的 execCtx 组装补 principalKind / onBehalfOf,与 runtime 侧同口径)+ 两面测试;⛔ 不做共享函数收敛重构(分诊钉死:另立单事项)、⛔ 不收窄 principalKind 为三值枚举('service'/'system' 在用)

执行依据:分诊 2026-08-06 17:03 已按 restore-invariant 入队(ADR-0090 D9/D10 已接受契约、REST 传输未兑现),范围/消费方/查重三项齐备。热文件纪律:派发时点已重查在飞 —— open PR 零触 rest-server.ts / resolve-execution-context.ts。必答项照分诊第 3 条:逐条枚举本次激活的判断分支与行为差量并钉住;若 guest 面从宽变严超出 ADR 声明意图,⛔ 停手升 needs_decision。

---

Generated by Claude Code

[qq9340100]

ACCEPT — PR #6205（cli 车道 PM,session session_01Wbxm29qPKnLf44AbSxizqW,step-7 验收)

逐项核对(均对照 GitHub 实读,非转述):

1. 前提与范围保真:开工前在 origin/main 80f7dc6a3(rc.5)上复核了 issue 前提——REST computeExecCtx 组装的 ExecutionContext 缺 principalKind,而 dispatcher 面已带。PR 文件面 3 个,与批准范围一致:changeset(@objectstack/rest patch)+ 新测试文件 + rest-server.ts 单点添加 principalKind: 'human'。无越界文件,无 content/docs/releases/ 触碰,Fixes 行在位。
2. 只补 'human' 的裁量成立:PR 正文与代码注释给出了可复核的理由——agent 需要 OAuth access token,而该通道只在 dispatcher /mcp(acceptOAuthAccessToken)接受;guest 在 REST 面不可表达,因为 computeExecCtx 无 userId 即返回 undefined(压根不产出 ctx)。onBehalfOf 保持 ABSENT 并被测试钉死,与 dispatcher 面对齐属实。
3. 强制问题(四个执法消费者):explain-engine.ts:95(guest⇒EXTERNAL)、security-plugin.ts:2679(isAgent)、action-execution.ts:1025(echo)、perf-timing.ts:475——dev 逐一验证 principalKind:'human' 在四处均 零激活、零授权增量,并有 perf-gate 对 human 关/admin 开的行为钉子。这正是本 issue 最大的风险点,已消除。
4. 反向验证:方向预判(去掉该行 ⇒ 3 条测试红,报错点名 13-key dogfood 键集)先行声明、后行证实,合格。
5. CI 亲读:23/23 job conclusion 均 success,其中 ESLint(携 check:* 家族)与 TypeScript Type Check(携 spec 门禁)为真实 conclusion,非 aggregate/in_progress 读数。
6. 界外发现处置正确:plugin-sharing/share-link 第三处组装缺 accessible_org_ids(group 姿态 fail-closed 403)未夹带进本 PR,单独立案 同族第三处组装:share-link 路由把授权信封裁成 4 个字段后直接当 enforcement context 喂给 engine.find —— group 租户姿态下 Layer 0 墙恒判否 #6206,合规。

处置:PR #6205 转 ready 并挂 auto-merge;两读数(merge queue + origin/main)确认 MERGED 后关单。dev 请求 PM 裁量的「双面组装收敛」整合单由我以 finding 立案,不随本单关闭而丢失。

---

Generated by Claude Code