`ScriptContext.user` 是 `unknown` —— 沙箱接缝上没有任何类型把 dispatcher 的 user 形状钉住(observation)

[baozhoutao]

Observation-class finding,来自 #5372 / PR #5518 的实施。今天没有用户会撞到,不影响任何运行行为 —— 记录的是一处"声明缺席"而非缺陷。

观察到的事实

ScriptContext(packages/runtime/src/sandbox/script-runner.ts:59)把交给 body 的调用者声明为:

user?: unknown;

而 ctx.user 在两个方向上都是有契约的:

• 谓词面已经有一个 spec 声明的契约 —— ADR-0068 D1 的 EvalUser(packages/spec/src/identity/eval-user.zod.ts),formula/stdlib.ts 的 buildScope 正是把它挂在 current_user / user / ctx.user 三个别名上;
• body 面在 PR fix(runtime): ctx.user.name 交付真实 display name —— 三条 dispatch 路径统一 user 形状 (#5372) #5518 之后由单一生产者 packages/runtime/src/security/actor-user.ts 构造,其身份内核就是同一个 createEvalUser。

也就是说值已经统一了,但类型系统对此一无所知:unknown 之下,第四个 dispatch 面明天再手搓一个 user 字面量,编译器不会说一句话 —— 而"三个 dispatcher 手搓出三种形状"正是 #5372 的成因。#5372 之所以能存在几个版本,部分原因就是没有任何声明可以违背。

为什么按 observation 归档而不是缺陷

• 运行时形状现在是对的,且有 pin 测试(packages/runtime/src/action-ctx-user-shape.test.ts 逐键、逐值断言三条路径相等);
• 该字段是沙箱的通用接缝(hook 与 action 共用),hook 路径的 user 来自引擎 engineCtx.user,与 dispatch 面不是同一个生产者 —— 直接把类型收紧成 ActorUser 会把 hook 面一起断言进来,需要先核 hook 侧交付的到底是什么形状。这是这条 finding 里唯一真正的工作量,也是它不适合顺手做进 Action context's ctx.user.name is hardcoded to the raw user id on the REST dispatch path — three dispatchers hand the sandbox three different user shapes #5372 的原因。

可能的方向(未裁决)

1. ScriptContext.user?: EvalUser(spec 契约,最小公分母),dispatch 面的传输键作为结构化扩展仍然合法;
2. 在 runtime 侧导出 ActorUser 并声明 user?: ActorUser | EvalUser;
3. 维持 unknown,改以闸门(而非类型)约束"user 形状只有一个生产者" —— 与 check:single-authz-resolver 同形。

需要先测 hook 面实际交付的形状再选。

会话:session_016FNvXhtSdnEGEfLEsMmvxh(仅记录,不认领)

[os-zhuang]

发现分诊轮判级:持有(留 finding,补挂 domain:cli 缓存落点判断 —— packages/runtime 归 cli 车道)。为什么还留着:运行时形状已统一且有逐键 pin 测试兜底,今天无任何用户可撞面;类型收紧的前置(核实 hook 面 engineCtx.user 实际交付形状)未做,三个方向未裁。重启条件:出现第四个 dispatch 面、或 hook 面形状核实完成时晋级。下轮分诊轮复核。

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

---

Generated by Claude Code