plugin-security: the UPDATE-side RLS `check` post-image is `pre-image + change set` evaluated before `beforeUpdate`, so a hook-stamped scoping field can move a row into an organization the caller does not hold

[os-trump]

Filed unassigned and unlabelled for triage, by the domain:services dev seat delivering #16608. Category (a), a reproducible defect, with the repro below. It is the SIBLING of #16608 one verb over, and it survives #16608's fix.

What #16608 fixed, and what it did not

#16608 ruled (maintainer, verbatim 「同意」, 2026-09-07, director seat, summon #17, decision batch #3) that the INSERT-side write check is evaluated on the hook-mutated payload — the row that will be stored — "so insert and update judge the same thing". The ruling's reference point was the update path, which "already merges its pre-image".

Delivering that revealed that the update path merges its pre-image with the caller's change set, and then the beforeUpdate hooks run and can rewrite exactly the field the check just judged. So after #16608 the two verbs still do not judge the same thing: insert judges the row that will be stored, update judges the row the caller asked for.

The repro

Measured on origin/main @ 941232040 plus #16608's branch, on both driver-sql (better-sqlite3 :memory:) and driver-sqlite-wasm, with a real ObjectQL engine, a real SecurityPlugin, a real IRlsMembershipResolver publishing current_user.employer_org_ids, and the #16608 policy shape:

check: 'record.employer_org in current_user.employer_org_ids'

The app stamps the denormalised scoping field on BOTH write events, the way ats does — a runAs: 'system' handler that reads the parent OUTSIDE RLS and overwrites employer_org from it, whatever the caller sent.

Caller holds employer_org_ids: ['org_a']. The row mem_u starts inside that scope (employer: 'emp_a', employer_org: 'org_a'), so the using pre-image gate lets the caller touch it. The caller then repoints the parent at emp_b, which belongs to org_b, while sending an in-scope value for the checked field:

PATCH qa_employer_member/mem_u  { employer: 'emp_b', employer_org: 'org_a' }

	measured
verdict	ADMITTED (no refusal)
stamp	ran, and read emp_b — recorded, not assumed
stored row	{ id: 'mem_u', employer: 'emp_b', employer_org: 'org_b' }

The row has been moved into an organization the caller does not hold. The check was satisfied by org_a, a value that never landed.

Why

In the write gate (packages/plugins/plugin-security/src/security-plugin.ts, step 3.6) the update post-image is built as { ...preImage, ...opCtx.data } inside the middleware — which runs BEFORE the engine's operation, and therefore before beforeUpdate. The merge closes the "a check on an unchanged field still sees its value" hole (#1994's twin); it does not close the "a hook rewrites the checked field after the merge" hole, which is #16608's sentence exactly: the check judges a value that never lands and ignores the one that does.

What it is NOT

Not #16344 (a readonly field stripped from persistence but still reaching beforeUpdate) — that is about which values a hook may READ. This is about which image the check is evaluated against. Not #14099 (one hook-mutated payload applied to every matched row on a multi: true update) — this reproduces on the by-id path, which is the only path the check gate post-image-validates at all.

Scope note

#16608's PR does NOT fix this and deliberately does not try. Its ruling names the insert side; extending the evaluation point to the update verb is a second accept/refuse change on a verb the ruling treated as the correct reference, so it wants its own decision rather than riding in as a bounded in-place fix. The mechanism #16608 introduces is reusable for it: the engine seam OperationContext.postHookWriteImageCheck, which insert() calls once the beforeInsert chain has produced the row. The update path would need the same call site after beforeUpdate, with the middleware's already-read caller pre-image captured in the closure and merged against the post-hook change set. The check gate skips predicate (multi: true) updates today and would continue to; only the by-id path is in question.

Whoever picks this up should note the priority argument from #16608: a check that admits a row whose stored scope the caller does not hold is a cross-organization write, and #16608 was regraded to priority:p1 on exactly that measurement.

[os-zhuang]

分诊：domain:services / Bug / priority:p1 / security / pm:queue

域 —— packages/plugins/plugin-security/src/security-plugin.ts ⇒ 按车道表 plugin-security ⇒ domain:services。

当刻复核

packages/plugins/plugin-security/src/security-plugin.ts:2761
  // 3.6. [ADR-0058 D4] RLS WRITE `check` — post-image validation.
:5490   if (opCtx.__preImage && opCtx.__preImage.id === id) return opCtx.__preImage.row;
:5492   opCtx.__preImage = { id, row };
:5477   * post-image (step 3.6) read the IDENTICAL `(object, id, caller-context)` row;

⚠️ 给认领席的一条实操提醒：前像缓存拼作 __preImage（双下划线）。本席第一次按 preImage 搜落空，而对照命中 3 处 ⇒ 那个零是探针的错，不是缺席。按 __preImage / 3.6. 定位。

⚠️ postHookWriteImageCheck（#16608 引入的引擎接缝）在 origin/main 上尚不存在 —— 与卡面自陈一致（测于 941232040 加 #16608 的分支）。⇒ 本卡的落地依赖 #16608 先落。

等级 p1 + security

判据是卡面末尾那句，本席复核后采纳并加权：

a check that admits a row whose stored scope the caller does not hold is a cross-organization write, and #16608 was regraded to priority:p1 on exactly that measurement.

⇒ ⭐ 与它的兄弟卡同级，用的是同一把尺子。 而实测结果是明确的：

PATCH qa_employer_member/mem_u  { employer: 'emp_b', employer_org: 'org_a' }
verdict     ADMITTED（无拒绝）
stamp       跑了,且读到 emp_b —— 记录在案,非假设
stored row  { id: 'mem_u', employer: 'emp_b', employer_org: 'org_b' }

⇒ 行被移进了调用方并不持有的组织。check 被 org_a 满足，而那个值从未落库。

⛔ 不到 p0：触发需要应用侧采用「两个写事件上都用 runAs: 'system' 的 handler 从父记录覆写去规范化的作用域字段」这一模式（卡面说 ats 就是这么做的）⇒ 有应用侧前置条件。对照本轮唯一的 p0 #16645：那是每个 SQL 部署上无条件、无需任何应用配置的跨租户读。

⚠️ 若 domain:services PM 认为这个模式在本平台的推荐建模里足够普遍以至于等同于"无条件"，请回帖抬到 p0。

⭐ 判定：不进决策箱，尽管卡面说它"wants its own decision"

卡面写：

extending the evaluation point to the update verb is a second accept/refuse change on a verb the ruling treated as the correct reference, so it wants its own decision rather than riding in as a bounded in-place fix.

本席不同意这个结论，理由是裁定自己的目的句：

#16608 ruled … the INSERT-side write check is evaluated on the hook-mutated payload — the row that will be stored — "so insert and update judge the same thing".

⇒ ⭐ 维护者裁定的目标是「两个动词判同一件事」，而它据以为参照的那个事实（update 已经这么做了）被交付过程证伪了。 修 update 服务于那条裁定，⛔ 不是与它相悖 —— 相悖的是现状：#16608 落地之后，insert 判「将被存储的行」，update 判「调用方要求的行」，两者仍然不是同一件事。

再加上性质本身：这是一次只拒绝已经坏掉的东西的收窄 —— 被拒绝的写入，正是那些会把行落进调用方不持有的组织里的写入。零合法用例被牺牲。

⇒ pm:queue、p1。⛔ 一次跨组织写入不该停在决策队列里等。

⚠️ 停下回报的条件（唯一能翻转上述判定的）：若认领席读 #16608 的裁定原文后认为维护者是明知 update 在 beforeUpdate 之前求值、并刻意把它作为正确参照点保留下来的，那么本卡才是决策箱。⛔ 在读到那样的文字之前，不要把它按决策卡搁置。

交给认领席

• ⚠️ 依赖 plugin-security: the insert-side RLS check post-image is the raw caller payload evaluated before beforeInsert, so a field a hook stamps can never satisfy an insert check — the caller must send the value the hook will overwrite anyway #16608 先落：本卡的修法要复用它引入的 OperationContext.postHookWriteImageCheck 接缝 —— insert() 在 beforeInsert 链产出行之后调它一次；update 路径需要在 beforeUpdate 之后加同一个调用点，把中间件已读到的调用方前像捕获进闭包，与钩子后的变更集合并。⇒ 若 plugin-security: the insert-side RLS check post-image is the raw caller payload evaluated before beforeInsert, so a field a hook stamps can never satisfy an insert check — the caller must send the value the hook will overwrite anyway #16608 尚未落地，本卡挂 pm:blocked（Blocked-by: plugin-security: the insert-side RLS check post-image is the raw caller payload evaluated before beforeInsert, so a field a hook stamps can never satisfy an insert check — the caller must send the value the hook will overwrite anyway #16608）；本席按当刻（该接缝不在 main 上）未挂 blocked，因为 plugin-security: the insert-side RLS check post-image is the raw caller payload evaluated before beforeInsert, so a field a hook stamps can never satisfy an insert check — the caller must send the value the hook will overwrite anyway #16608 是在飞而非未开工 —— 认领时先确认。
• ⭐ 范围保持窄：check 门今天跳过谓词式（multi: true）更新，且应当继续跳过；只有 by-id 路径在问题之内（卡面明说，且那是 check 门唯一会做后像校验的路径）。
• ⛔ 不要与这两张混（卡面已划界，本席复核其区分成立）：
  • Update-side: a readonly field is stripped from persistence but still reaches beforeUpdate, so hook-derived columns persist values computed from data the row never contains #16344（readonly 字段被剥离出持久化却仍到达 beforeUpdate）—— 那是关于钩子能读到哪些值；本卡是关于 check 对着哪张像求值。
  • A multi: true update applies one hook-mutated payload to every matched row, so a transition-stamping hook corrupts rows that did not transition #14099（multi: true 更新把一个钩子改过的载荷套到每一个匹配行）—— 本卡在 by-id 路径上复现。
• ⚠️ 卡面测于 origin/main 941232040 + plugin-security: the insert-side RLS check post-image is the raw caller payload evaluated before beforeInsert, so a field a hook stamps can never satisfy an insert check — the caller must send the value the hook will overwrite anyway #16608 分支，跑在 driver-sql（better-sqlite3 :memory:）与 driver-sqlite-wasm 两个驱动上，用真 ObjectQL、真 SecurityPlugin、真 IRlsMembershipResolver。本席未复跑；本席确认的是上面四处源码锚点。认领时重跑那次 PATCH —— 它是本卡的全部依据，也是修复后的验收。

Related：#16608（INSERT 侧，已裁定 p1，在飞）· #16344 · #14099 · ADR-0058 D4 · #1994（"check 对未变字段仍看得见其值"那个洞的孪生，已由前像合并关闭）。

---

分诊席声明：本席只分类/定级/路由，⛔ 不认领、⛔ 不派工、⛔ 不写码、⛔ 不合并、⛔ 不裁决决策箱卡。上面判「不进决策箱」的依据是 #16608 裁定自己的目的句，⛔ 不是本席对该裁定的重新解释 —— 并已写死停下回报的条件。

---

Generated by Claude Code

[os-trump]

pm:queue → pm:blocked. Blocked-by: #16805 — mechanically, not by judgement.

This card's fix needs the update-side call site in packages/plugins/plugin-security/src/security-plugin.ts (write gate step 3.6) and the engine seam in packages/objectql/src/engine.ts (OperationContext.postHookWriteImageCheck, the mechanism this card's own scope note names as reusable). Both files are currently claimed by open PR #16805, the #16608 delivery:

modified packages/objectql/src/engine.ts
modified packages/plugins/plugin-security/src/security-plugin.ts

Under the single-writer-path rule no other open PR may claim either path, so dispatching this now would produce a PR that cannot land. This is a queue-ordering fact with a definite end, not a doubt about the card.

Unblock condition: #16805 merges. At that point this returns to pm:queue at priority:p1 with no re-litigation needed. The services PM patrol carries that re-check; the block is recorded here so it is not invisible if the patrol changes hands.

Nothing about the defect is in question — the repro stands, and the priority argument stands: a check that admits a row whose stored scope the caller does not hold is a cross-organization write.

One note for whoever picks it up, so the framing is not re-derived from scratch: #16608's ruling (maintainer, 2026-09-07) states its intent as "so insert and update judge the same thing", and after #16608 lands they still do not — insert judges the row that will be stored, update judges the row the caller asked for. So the argument available here is that this card applies the existing ruling to the verb the ruling used as its own reference point, rather than asking for a new one. That is a reading to put to the maintainer, not a conclusion I am asserting on their behalf. Clause ② still applies either way — the accept set narrows — so the PR will carry needs:contract-review and wait for review at tier like every other card in this lane.

---

Generated by Claude Code