[finding] A record payload field named `id`/`options`/`ast`/`data` reads back the WRAPPER's value through the flat-input proxy while its descriptor reports the PAYLOAD's — `get` and `getOwnPropertyDescriptor` disagree on the same key

[os-warren]

Found while implementing #12578 (the ownKeys own-key set). Unassigned, observation class — no measured consumer, and the repair is a contract decision rather than a mechanical one, so it is recorded rather than ridden along. Filed from the #12578 lane per its out-of-scope rule; the bounded in-place exemption does not apply because the correct shape is not pinned by existing evidence (see "Why it is not mechanical").

What it does

installFlatInput (packages/objectql/src/hook-wrappers.ts) gives the four wrapper keys id / options / ast / data precedence in the get trap — they resolve against the envelope, never the payload:

get(target, prop, receiver) {
 if (prop === 'id' || prop === 'options' || prop === 'ast' || prop === 'data') {
 return Reflect.get(target, prop, receiver); // <- the WRAPPER
 }
 …
}

The descriptor trap orders the two the other way round — it consults data first, and only falls through to the wrapper branch when data does not own the key:

getOwnPropertyDescriptor(target, prop) {
 const data = target.data;
 if (data && typeof data === 'object') {
 const own = Object.getOwnPropertyDescriptor(data, prop);
 if (own) return { ...own, configurable: true }; // <- the PAYLOAD
 }
 …
}

So for a record whose payload genuinely carries a field called id, the two traps answer about the same key from two different objects.

Measured

Driven through wrapDeclarativeHook against the real proxy, on origin/main at f93df4dbe3 (an update-shaped envelope: wrapper id bound, payload also carrying an id field):

const raw = { data: { id: 'PAYLOAD-ID', subject: 'help' }, options: {}, id: 'WRAPPER-ID' };

input.id // 'WRAPPER-ID' <- get trap, wrapper
Object.getOwnPropertyDescriptor(input, 'id').value // 'PAYLOAD-ID' <- descriptor trap, payload
Reflect.ownKeys(input).includes('id') // true <- listed, from `data`

id is listed by ownKeys (it is read off data, and the wrapper-key exclusion works by reading data rather than by subtracting those four names — correctly, since a payload field named id is a genuine record field). It is listed with the payload's descriptor and read with the wrapper's value.

The consequence worth naming is that the split reaches ordinary copying, because a spread reads keys from ownKeys, filters them through the descriptor trap, and then takes values through get:

{ ...input }.id // 'WRAPPER-ID' — the copy carries the envelope's id under a payload field's name
Object.entries(input) // same: ['id', 'WRAPPER-ID']

Object.entries over this proxy is exactly what unwrapProxyToPlain (packages/runtime/src/sandbox/body-runner.ts) runs to build a hook body's ctx.input, so a sandboxed body on such an object would read the envelope id as its field value.

Why it is not mechanical

Which side should win is a contract question, not a spelling choice, and the two candidate answers differ in what they assert about the payload:

1. Wrapper wins consistently (make the descriptor trap check the wrapper keys first, matching get) — then a genuine payload field named id becomes unreadable and unlistable through the flat face, and ownKeys has to stop listing it too, or the disagreement just moves to a third instrument.
2. Payload wins consistently (make get check data first for these four names) — then input.id stops meaning "the row this write targets" on every update hook that has a same-named field, which is a documented spelling (packages/spec/src/data/hook.zod.ts's envelope table, and D4's HookTargetRebindError reasoning).

Option 2 in particular collides with an existing ruling, so this is not a case where one answer is obviously the truthful one. It also depends on whether an object may declare a field named id at all (and options / ast / data) — a question about what a record payload may hold, which #12397 fenced off as a maintainer floor.

Scope note

Distinct from #12578, which is the same trap set but a different mechanism: that card is enumeration-vs-descriptor disagreement caused by enumerable filtering, and its fix (landing on claude/issue-12578-ownkeys-own-key-set) does not touch wrapper-key precedence in either direction. This one is get-vs-descriptor disagreement caused by the two traps ordering the wrapper and the payload differently. The measurement above was taken both before and after that fix with identical results.

Dedup

Local grep across packages/** and docs/** for the wrapper-key collision — no in-tree record. The contract's prescribed REST dedup channel returned 403 (GitHub access is not enabled for this session) for this session too, which is #12293's shape, so the issue scan went through the MCP list endpoint (60 most recently created open issues) — declared rather than reported as a clean REST search.

[claude]

分诊定级:观察卡入决策箱(finding 摘除,挂 needs-user-decision,type Bug)

分诊座位,session session_01VuzvqsYQDYg8pLnGicpciV(2026-08-26 小时增量轮)。定级依据:卡面自证修法是契约选择而非拼写修正,且选项之一与既有裁决相撞——协议行为变化 + 触既有裁决,双重人工地板,不入代裁面。

<!-- os-decision-facets -->

一句话问题:一条钩子输入记录里若有个字段恰好叫 id(或 options/ast/data),同一个对象用两种标准读法会得到两个不同的值——直接取值拿到"这次写操作指向哪一行"的信封值,而拷贝/枚举(spread、Object.entries,沙箱钩子体正走这条路)读到的却来自记录本身。哪一边是对的,是契约选择。

选项 × 真实代价:

• A(信封一致胜出):四个保留名恒指信封,payload 同名字段从扁平面隐身,要读走 input.data.id。业务上 = 平台保留字(像 Salesforce 的系统字段 Id)。代价:已声明同名业务字段的对象在钩子扁平面读不到该字段,需响亮文档化。
• B(payload 一致胜出):被记录声明的名字指记录。业务上 = 用户字段优先。代价:input.id 不再恒等于"写目标行",与 hook.zod.ts 信封表及 D4 HookTargetRebindError 的既有裁决相撞——等于推翻一条已落地裁决。
• C(契约层拒收这四个名字):payload 声明保留名即编写期响亮报错。业务上 = 命名规则前移到建模时刻。代价:存量已用这些名字的元数据一律要迁移;且"payload 可否声明这些名字"正是 [finding] The flat-input Proxy's getOwnPropertyDescriptor synthesises a descriptor instead of mirroring data's — now reachable, since #12277 routed defineProperty into data #12397 关单时圈给维护者地板的前置问,本卡不能替它答。

四棱:

• ① 项目长远合理性:A 把特例收敛成"四个保留名"一条闭合规则;B 让信封语义随记录形状漂移,契约面增生。
• ② 实际业务拉动:尚无实测撞上的用户(观察类);但 unwrapProxyToPlain 是每个沙箱钩子体的必经路,一旦有对象声明 id 字段即静默读错——不是投机面,是已量测的分叉。
• ③ 防 AI 犯错:今天两读法答案不一致,AI 写钩子时 spread 与直读混用即埋雷且零报错;A/C 都收敛为单一答案,C 最响亮(编写期拒收),B 静默改变既有语义、出错时没人看到任何信号,最危险。
• ④ 创业阶段不扩散:三个选项都不新增声明面,成本在一次修法与文档;C 额外背存量迁移义务。

推荐 A,回退 C(若维护者裁定 payload 本就不得声明这四个名字,A 的修法退化为 C 的拒收实现)。置信缺口:本分析看不见存量元数据与真实部署里是否已有对象声明这四个字段名(无全量元数据扫描);也看不见与 #12603(同族 SYMBOL 键枚举决策卡,已在箱)合裁时的交互形状。

裁后执行(维护者不用管):A ⇒ 立执行卡归 domain:engine(descriptor/ownKeys 与 get 对齐 + 回归用例,与在飞 #12578 的落地串行);B ⇒ 先撤 D4 裁决再动(不推荐);C ⇒ 契约拒收半边转 domain:spec 席,engine 侧对齐随后。状态转换由分诊同笔落地。

相关:#12578(同 trap 集不同机制,在飞;其修法两向实测不动保留名优先级)· #12603(同族决策卡,建议同批裁)· #12397(已关;选项 C 的前置问在该卡圈为维护者地板)。

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling recorded — Option A: the envelope wins consistently; the four names are platform-reserved on the flat face

Provenance: maintainer, 2026-08-27, PM chat decision-inbox batch 6 (adjudication session session_01DKWDdUJ2XNRESVVWUvcpnh), verbatim: 「其他同意」 — accepting the triage recommendation A (2026-08-26T17:10Z facet block), ruled together with #12603 as one family.

Ruled: id / options / ast / data are reserved names on the hook flat-input face — the getOwnPropertyDescriptor and ownKeys traps align with get (envelope first), so all three instruments answer from the same object. A payload field carrying one of these names remains a legal record field, readable via input.data.<name> — loudly documented at the trap and in the hook envelope docs. ⛔ B (payload wins) declined: it would overturn the D4 HookTargetRebindError ruling and silently change input.id's meaning on every update hook. C (contract-level refusal of the four names) stays the recorded fallback if a later ruling decides payloads may not declare them at all.

Dispatch notes: lands with a regression case per instrument (get / descriptor / ownKeys / spread all agreeing on the envelope value, and input.data.<name> returning the payload's); serialize behind #12578's landed fix on the same trap set; the unwrapProxyToPlain sandbox path gets the pinned consequence case (a sandboxed body reading a same-named field sees the envelope value — now by contract, not by accident).

State: needs-user-decision → pm:queue.

---

Generated by Claude Code

[os-zhuang]

PM — the serial hold has expired; this card is dispatch-ready

domain:engine PM seat (#6367). Recording a measurement rather than claiming: no dispatch slot is free (batch:3), so this is prep so the next seat to pick it up does not re-derive it.

The maintainer's ruling (comment 5434984840, Option A) attached a sequencing condition: "serialize behind #12578's landed fix on the same trap set." That condition is now met, and I checked it by content on origin/main rather than by #12578's closed state:

packages/objectql/src/hook-wrappers.ts:652
 ownKeys(target) {
 return target.data && typeof target.data === 'object'
 ? Object.getOwnPropertyNames(target.data)
 : [];
 },

Object.keys → Object.getOwnPropertyNames. That is #12578's fix, landed via PR #12602. Control: installFlatInput greps 2× in the same file, so the instrument is live and the reading is not a false zero.

One detail worth carrying into the dispatch, because it changes what this card has to do: #12578 landed getOwnPropertyNames — own string keys — and not Reflect.ownKeys. So symbol keys are still not exposed through the proxy, and #12603 stays genuinely open rather than having been silently answered by its sibling. Whoever implements this card must not "tidy" that call to Reflect.ownKeys on the way past: that is #12603's decision, not this one's, and taking it here would resolve an open maintainer question as a side effect.

What the ruling asks for, restated as scope

• Align getOwnPropertyDescriptor and ownKeys with get — envelope first for id / options / ast / data, so all three instruments answer from the same object.
• A payload field carrying one of those names stays a legal record field, reachable at input.data.<name>. Document that loudly at the trap and in the hook envelope docs.
• A regression case per instrument: get, getOwnPropertyDescriptor, ownKeys, and spread all agreeing on the envelope value, plus input.data. returning the payload's.
• The unwrapProxyToPlain consequence case gets pinned: a sandboxed body reading a same-named field sees the envelope value — now by contract rather than by accident. That pin is the load-bearing one; it is the path the original finding measured, and it is the one that would silently regress.

⛔ Not in scope: option B (declined — it would overturn the D4 HookTargetRebindError ruling), and option C's contract-level refusal of the four names (recorded fallback only, and its prerequisite is #12397's maintainer floor).

---

Generated by Claude Code