fix(plugin-security, objectql): a row-level check holds for every row of an array insert and a predicate update

[objectstack-fleet]

Fixes #19950
Fixes #19964
Clause-②: no (narrowing)

What this fixes

A row-level security check (declared on the policy, or defaulted from its using) is the write-side half of the policy: a row the check refuses is never stored (ADR-0058 D4: "on the write pre-image path that already exists for by-id writes … and on the AST-injected bulk path"). The write gate enforced it for a single-row insert and a by-id update, and not for the two multi-row write shapes:

• [finding] security: a row-level check (declared, or defaulted from using) is never evaluated on an ARRAY insert — engine.insert(object, [rows]), which createManyData calls, stores rows a single-record insert refuses #19964, array insert. Step 3.6 excluded an array payload, so no judgement was installed and every row was stored unjudged, including under configurations that refuse every single-row insert.
• security: a check-only row-level policy does not gate a bulk update (update(…, { where, multi: true })): the post-image check is skipped as "governed by the using-scoped where", and no using exists to scope it #19950, predicate update (multi: true, no row address). Step 3.6 skipped the new-row check and logged "governed by the using-scoped where". A policy that declares only check scopes nothing, and a scoped where says nothing about the new row in any case. The skip was unconditional, so it also covered a declared check that differs from using and a check defaulted from using.

Both shapes are now judged row by row with the existing refusal (PERMISSION_DENIED / 403, nothing stored). One failing row refuses the whole write. The judgement is the existing satisfiesCheck over matchesFilterCondition: no predicate is compiled differently, and nothing is lowered into the where, so no compile surface moves.

Landing: two packages, and why the engine is one of them

• packages/plugins/plugin-security/src/security-plugin.ts, step 3.6 plus the seam declaration and the post-next() fail-closed guard (generalised from "the insert" to the operation). The by-id update branch is unchanged. The explainAccessForCaller wiring is not touched.

• packages/objectql/src/engine.ts, the predicate-update branch of update() (domain:engine), plus the seam's doc comments. Why the producer is the engine (measured, not assumed): the rows a predicate update changes are the rows the middleware-COMPOSED AST selects. That AST is complete only after every middleware has run: step 3 of this middleware composes its own scope after step 3.6, and plugin-sharing composes its editable-rows filter onto the same AST (sharing-plugin.ts:1405), in plugin order. The suggested route, reading "under the caller's context" in the middleware, was measured two ways and does not hold:

  • A caller-context read applies READ scope and field masking. Where the read scope is narrower than the write scope, written rows go unjudged (fail-open). Where it is wider, rows that will not be written get judged (false refusals). Ablation 3 below shows the second: a judgement that is not over the actual matched rows falsely refuses the USING-only in-scope control.
  • The engine already holds the exact set: the D7 matched-row read (readPriorRows, bound to the composed AST), which the ruling says is read once and reused, and which already serves validation, the readonlyWhen strip and both per-row hook phases.

  So the security layer installs its judgement on the existing OperationContext.postHookWriteImageCheck seam (the one fix(plugin-security): a USING-only RLS policy holds INSERT and UPDATE rows to its using #19952 built for inserts), and the engine calls it on the predicate branch. It hands over every matched row merged with the payload (the same shape as the per-row afterUpdate result), placed after assertNoStrictDrops(), where the payload is final. That placement follows the insert seam's contract review: "the row the seam judges must be the row that is stored". The readonly strips run earlier on this branch, so a pre-strip placement would judge values that never land.

Mechanism hypotheses (dispatch Section 2), as measured on 2c1011b01b

1. Held. Line 3000 carried !Array.isArray(opCtx.data). Lines 3078-3083 set postImage = null for extractSingleId(opCtx) == null and logged "governed by the using-scoped where".
2. Held. engine.ts (the postHookWriteImageCheck call in insert()) hands evaluate every live row of an array insert. The array fix is plugin-side only.
3. Refined. The memoized getCallerPreImage is by-id and caller-context, so it is not reusable per row for the reasons above. The engine's memo serves instead, at no extra read wherever per-row hooks already read it.
4. Held. The skip was unconditional. A cell pins a using plus a differing check.

One further hole, found and closed: the middleware treats a falsy scalar id ('', 0) as a row address, and the engine does not (resolveEngineUpdateDispatch). A falsy payload id therefore carried a bulk update past the per-row judgement, admitted on a change-set-only image. The seam is now installed whenever the engine will not treat the write as addressing one row. The falsy case keeps its by-id judgement too, so it only refuses more.

Surface beyond the claim, with reasons

• packages/objectql/src/engine.ts: see above (cross-lane, domain:engine).
• Existing plugin-security tests: check-only-write-scope.test.ts and security-plugin.test.ts carry engine doubles that must now honour the seam on a predicate update, the way the real engine does. Otherwise the fail-closed guard refuses them, which is the intended behaviour. One test title and comment said step 3.6 "declines to check" the bulk path; it now says 3.6 can refuse a bulk write but never scope one. That pin still discriminates a site-1 revert, now by refusal. Two comment-only edits (rls-check-defaults-to-using.test.ts, rls-phantom-column-negation.test.ts) stated the array exclusion as a fact.
• A pending release note, corrected in place: .changeset/rls-check-defaults-to-using.md (from fix(plugin-security): a USING-only RLS policy holds INSERT and UPDATE rows to its using #19952, not yet released). Its "What does not change" list said bulk updates "are not checked row by row", which this PR makes false. The bullet now says their new rows are checked row by row too, by this PR's entry. check-empty-changeset is RED on this by design: it is the DELIBERATE CORRECTION class (ruling D on finding: random changeset filenames collide silently across parallel agents — a round overwrote a sibling PR's minor changeset and every gate stayed green #17712). Its prescribed remedy is to keep the correction and get it confirmed on the PR; restoring the file would publish a false sentence. Under the landing rule pm-dispatch: three landings the seat decides on its own record (ruling 1A, 2A, 3A) #19970 set, 「DELIBERATE CORRECTION 红:同 head 达档复核 PASS 记录即确认,⛔ 不等维护者」, the confirmation is a same-head at-tier review record with a PASS verdict, not the maintainer. The red is expected until that record is on the PR for the landing head.

Behaviour that changes (all in the refusing direction)

• A predicate update under a check-only policy is refused when any matched row's new image fails the check.
• A predicate update that moves a matched row out of a policy's using, when no applicable policy declares check, is refused: the defaulted check, which is the answer the by-id update has given since fix(plugin-security): a USING-only RLS policy holds INSERT and UPDATE rows to its using #19952. Triage's "已声明 using 的策略,行为保持不变" is held as: in-scope bulk updates under a using policy are admitted and scoped exactly as before (pinned). Only a bulk write that moves rows out of the using is newly refused, on the same terms as by-id. The seat confirmed this reading: by-id and bulk are two implementations of one operation and must not disagree (RowLevelSecurityPolicySchema.check 「defaults to USING clause if not specified」; ADR-0058 D4).
• An array insert is refused when any row fails, including every configuration that already refused each single insert.
• A host that installs the judgement on a predicate update and never runs it is refused (403, error log), as an insert already is.

Tests

Patch round 2 (head 3247efeecd, after merging origin/main 9bfbacbf8b as merge commit 938b2acfde): rls-check-multi-row-writes.test.ts 32 passed (32); plugin-security suite 123 files, 2348 tests passed; objectql re-run because #19979 touched that package: local project 155 files / 2434 tests + 154 files / 2758 tests, repo project 1 file / 5 tests; typecheck green for objectql and plugin-security (VERDICT command-exit 0 each).

Patch round 1 (head 9fff66cfdc, after merging origin/main 3fd3a4f91b as merge commit a5ca1db166): rls-check-multi-row-writes.test.ts 32 passed (32); plugin-security suite 123 files, 2348 tests passed (VERDICT command-exit 0 each). The merge brought no change under packages/objectql or packages/plugins/plugin-security, so the objectql suite was not re-run; its last run is the one below, on a byte-identical engine.ts.

Round 1 (head 6d28dfe98d):

New: packages/plugins/plugin-security/src/rls-check-multi-row-writes.test.ts, 32 cells on driver-sql (better-sqlite3) and driver-sqlite-wasm, real SecurityPlugin + ObjectQL.

• Failing first, on the unmodified tree: 18 red and 12 green (the controls). Every negative cell failed as "admitted" (expected true to be false). In the unresolvable-policy cells the single-insert leg was refused and only the array leg was admitted.
• security: a check-only row-level policy does not gate a bulk update (update(…, { where, multi: true })): the post-image check is skipped as "governed by the using-scoped where", and no using exists to scope it #19950 cells: the check-only repro; per row not per change set (a matched row failing on an unchanged field refuses the whole write); using plus a differing check; fail-closed (an inner middleware strips the seam, and the write is refused with "the update on 'qa_ticket' was executed without the row-level CHECK being evaluated"); falsy payload id. Controls: over-fix admit, USING-only in-scope admit and scoped, using+check in-scope admit, by-id unchanged, and USING-only move-out refused on both bulk and by-id.
• [finding] security: a row-level check (declared, or defaulted from using) is never evaluated on an ARRAY insert — engine.insert(object, [rows]), which createManyData calls, stores rows a single-record insert refuses #19964 cells: the [admitted, refused] repro; over-fix admit; single insert unchanged; three refuse-every-insert configurations (an unresolvable sole using on insert and on all, an unresolvable declared check).
• Every refusal asserts code PERMISSION_DENIED, status 403 and the developer half naming the gate and verb, then reads the stored rows back under a system context.

Suites: plugin-security 123 files, 2348 tests pass. objectql 309 files, 5182 tests pass (local project in two halves, plus the repo project). typecheck is green for both packages (plugin-security test-layer debt: 0 files, 0 errors).

Ablations: each committed first, mutated through scripts/ablation-replace.mjs (anchor hit 1 to 0, blob changed), restored with blob equal to HEAD and an empty git diff HEAD. Resolution path: the plugin is imported relatively, and @objectstack/objectql is aliased to src/index.ts in this package's vitest.config.ts, so no dist/ sits between the mutation and the test.

#	mutation	result
1	restore the non-array guard for inserts	8 red: the 4 array-insert negative cells x 2 drivers
2	never install the seam on a predicate update	12 red: the 6 bulk negative cells x 2
3	engine judges the payload alone, not the matched rows	6 red: the per-row cell, the falsy-id cell, and the USING-only in-scope control (falsely refused)
4	install only when the id is null (falsy counts as by-id)	2 red: the falsy-id cell, admitted
5	engine never calls the seam	16 red: refusals now carry the not-evaluated message, controls refused
6	disable the post-next() fail-closed guard	2 red: the fail-closed cell, admitted

Gates

Patch round 2 (head 3247efeecd): the four comment lines this change rewrote now cite the surviving record, commit a016f08b8a (the insert-side check), instead of a card that answers 404, and say in words that the original card no longer resolves. GITHUB_TOKEN="$GH_TOKEN" node scripts/check-issue-citations.mjs probes the board and exits 0: "every citation this change adds resolves (or is a declared cross-repo reference)", with 9 judged, 9 resolving and 0 unresolved added. dispatch-gates --commands derived the same 68 families from the same 9 paths against merge base 9bfbacbf8. All 68 were run; --ran answers "68 derived, 68 run, 0 NOT-MEASURED, 0 UNRUN". 67 exit 0. check-empty-changeset exits 1 on .changeset/rls-check-defaults-to-using.md only.

Patch round 1 (head 9fff66cfdc): dispatch-gates --commands derived the same 68 families from the same 9 paths, now against merge base 3fd3a4f91. All 68 were run; --ran answers "68 derived, 68 run, 0 NOT-MEASURED, 0 UNRUN". 67 exit 0. check-empty-changeset exits 1 on .changeset/rls-check-defaults-to-using.md only (the deliberate correction under "Surface beyond the claim"). The changeset gates the seat named: check-adr-0087-registration --base origin/main exits 0 ("1 declared-breaking changeset(s), each carrying an ADR-0087 disposition"), check-changeset-no-major --base origin/main exits 0, and pnpm check:changeset-gate-self-tests exits 0.

Round 1 (head 6d28dfe98d):

• node scripts/pm/dispatch-gates.mjs --commands derived 68 families from the 9 changed paths. All 68 were run with exit codes recorded. --ran answers "68 derived, 68 run, 0 NOT-MEASURED, 0 UNRUN".
• 67 exit 0. One exits 1: check-empty-changeset, the deliberate correction above.
• Three first answered PREREQUISITE NOT MET (exit 3): check:dual-build-cjs-loads, check:i18n and check:type-check-debt. They pass after the workspace closure build. check-engine-split-ratio passes after deepening the shallow clone to its window.
• Lint, as a proven narrowing: eslint --no-inline-config --format json over the 7 changed .ts files reports 7 files linted, 0 errors and 0 warnings. All 7 fall in the config's **/*.{ts,…} block. The config never enables type-aware linting (eslint.config.mjs:326-328), so this diff cannot move a verdict on an untouched file. The full pnpm lint is CI's.

Acceptance notes

• Refusal cost on the predicate path. The judgement runs where the payload is final, after the per-row beforeUpdate hooks and after the credential channel (encryptSecretFields), which runs above the strips on this branch. A refused bulk update whose payload carries a secret field has therefore already minted its sys_secret row. A validation refusal two lines below pays the same cost today. Moving the credential channel below the strips is a separate engine change. A check naming a secret field judges the stored reference.
• Image timing differs between the two update paths. A predicate update is judged on the post-hook image; a by-id update is still judged in the middleware on the pre-hook change set merged with the caller-visible pre-image. Where a beforeUpdate hook rewrites a checked field, the bulk path is the stricter of the two. The by-id path is untouched here.
• Read cost. On an object with no per-row hooks, a checked predicate update now reads its matched rows. The read is unbounded by the per-row hook ceiling, which applies only when hooks dispatch. On a kernel with the usual global hooks the read already happens and is shared.
• Partial-row array insert (__partialRowErrors): a failing row refuses the whole call rather than being reported per row.
• Version skew. A plugin-security built from this change, run over an engine without the predicate-path call, refuses checked bulk updates (fail-closed). Both packages carry the changeset.
• .changeset/19950-rls-check-multi-row-writes.md is declared a narrowing, per the seat's ruling and following fix(plugin-security): a USING-only RLS policy holds INSERT and UPDATE rows to its using #19952: minor for @objectstack/plugin-security and @objectstack/objectql, a ! headline, Clause-②: no (narrowing), an ADR-0087 not-required (no-migration-prescription) disposition, and a BREAKING paragraph listing the newly refused writes and the remedy (declare check on the policy, or fix the data).
• origin/main was merged twice with merge commits, both clean with no regeneration owed: at 3fd3a4f91b (a5ca1db166) and at 9bfbacbf8b (938b2acfde). PR fix(plugin-security): explain's record update/delete verdict uses the by-id write path's inputs #19984 (plugin-security: the record-grained explain verdict for update is not computed with the write path's inputs — record.visible is false on rows the by-id PATCH admits, so every consumer hides Edit from permitted users #19963, the explain wiring in the same file) had not landed by the second merge.
• Patch round 2: citation fix only (four comment lines in security-plugin.ts); no behaviour change.

[github-actions]

📓 Docs Drift Check

This PR changes 2 package(s): @objectstack/objectql, @objectstack/plugin-security, touching 3 documentable anchor(s).

2 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/data-flow.mdx (via OperationContext (symbol, a top-level interface))
• content/docs/permissions/system-context.mdx (via OperationContext (symbol, a top-level interface))

What this run could not see

• 2 name(s) were too generic to anchor anything (single lowercase words)
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 27 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json cdc1ae03dd277edac2742a6dfe4eb2bf61afefc5 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from dfc2f7b5079048907c94bfc0007a6f9210e148b0 — the merge of head 3247efeecd57583655db1005b027b437b53b9eab into base cdc1ae03dd277edac2742a6dfe4eb2bf61afefc5, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin dfc2f7b5079048907c94bfc0007a6f9210e148b0 && git checkout dfc2f7b5079048907c94bfc0007a6f9210e148b0
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin cdc1ae03dd277edac2742a6dfe4eb2bf61afefc5 3247efeecd57583655db1005b027b437b53b9eab && git checkout -B drift-repro cdc1ae03dd277edac2742a6dfe4eb2bf61afefc5 && git merge --no-ff 3247efeecd57583655db1005b027b437b53b9eab

node scripts/docs-audit/affected-docs.mjs --json cdc1ae03dd277edac2742a6dfe4eb2bf61afefc5

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs cdc1ae03dd277edac2742a6dfe4eb2bf61afefc5 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

CI red on head 9fff66cfdc: two rows, two causes · domain:services seat · session_01Evb5jFDZGKQE9KG4jbMfMF · 2026-09-24T15:21Z

1. Lint & Repo Gates, this PR's to fix. Step 189, 「Issue citations this change adds resolve on the board」, flags #16608 as allocated-but-absent on four lines this diff rewrote in security-plugin.ts. The seat measured that #16608 and its PR #16805 both answer 404; the surviving record is merge commit a016f08b8a. Patch round 2 has gone to the dev: keep the number, add prose that it no longer resolves, and name a016f08b8a (the gate's own remedy, with no guessed replacement). Two steps behind it never ran, and are NOT MEASURED until the re-run.
2. Check Changeset, red by design. It is the DELIBERATE CORRECTION of the pending .changeset/rls-check-defaults-to-using.md. Under pm-dispatch: three landings the seat decides on its own record (ruling 1A, 2A, 3A) #19970 it is confirmed by a same-head at-tier review record; that record will be taken on the final head, after patch round 2.

---

Generated by Claude Code

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 3247efeecd

_{Rendered by an isolated at-tier reviewer and adopted by the domain:services seat (session_01Evb5jFDZGKQE9KG4jbMfMF). Under the DELIBERATE CORRECTION landing rule (#19970), this record is also the confirmation of the foreign-note edit: it names the note and judges each rewritten sentence.}

① Derived judgments

(a) Accept-set changes. Each is a narrowing only, and nothing previously refused is admitted.

• Array insert. The step-3.6 guard now admits an array for insert, so the seam is installed. ObjectQL.insert already hands the seam every live row after beforeInsert, so the seam is always honoured. The single-object insert is byte-equivalent: the former inline judgement became newWriteImageCheck(). An array payload on update stays excluded, as on main.
• Predicate update. Main's targetId == null branch (a warning, no judgement) now installs the seam whenever !targetId. The by-id branch keeps its three statements unchanged. A falsy scalar id is judged by-id as before and also gets the seam. The one shape the engine still routes by-id with a falsy payload id is already refused on main at step 2.7.
• The floor on the predicate path. It takes part on the same terms as step 3's bulk where-scope, so matched rows already satisfy it.
• OperationContext.postHookWriteImageCheck, a published @objectstack/objectql type. Its shape and export are unchanged; only the TSDoc moves. At runtime, update()'s predicate branch sets honoured = true after assertNoStrictDrops(), then evaluates each row from the D7 readPriorRows memo merged with the exact payload driver.updateMany receives. Zero matched rows evaluates [].
• The post-next() fail-closed guard is verb-neutral: unchanged for inserts, and new for predicate updates only against a host that bypasses the engine.

(b) Edited foreign note: .changeset/rls-check-defaults-to-using.md (#19952, b7c792bd2e, pending). One bullet was rewritten.

• Before: 「Bulk updates without a single id are still scoped by the using where clause and are not checked row by row.」
• After, sentence 1: 「Bulk updates without a single id are still scoped by the using where clause.」 TRUE. The step-3 AST composition is untouched, and the seam only throws; it never edits the AST.
• After, sentence 2: 「Their new rows are now checked row by row as well, by the separate multi-row entry (security: a check-only row-level policy does not gate a bulk update (update(…, { where, multi: true })): the post-image check is skipped as "governed by the using-scoped where", and no using exists to scope it #19950).」 TRUE on this head. Step 3.6 installs the seam for !targetId, the engine judges each matched row with the final payload, and .changeset/19950-rls-check-multi-row-writes.md is that entry.
• The removed clause 「and are not checked row by row」 would be FALSE on this head, so the correction is required: restoring the base text would publish a false sentence.

(c) No other sentence is false on this head, in either the foreign note or this PR's own changeset. For the foreign note that covers the ownership-floor bullet (scoped to the by-id gate, and true there), 「select policies never gate」, the modifyAllRecords bypass, and the uncompilable-using bullet (now also array inserts, pinned). This PR's changeset was checked sentence by sentence, including the four newly-refused bullets, 「by-id update and single-row insert judged exactly as before」, 「a system-context write is not gated」, and the create-many route.

② Semver level

Right, and complete. Shipped bytes move in exactly two packages, and both are declared:

• @objectstack/objectql (engine.ts) and @objectstack/plugin-security (security-plugin.ts), both minor, both published and in the fixed group. The five test files ship nothing.

An accept-set narrowing is breaking, and in the launch window breaking ships as minor (major would be refused by check-changeset-no-major). Its breaking-ness is carried by the ! headline, the BREAKING banner and the ADR-0087 disposition, the same shape #19952 used. Clause-②: no (narrowing) is truthful: no new export, no new accepted key, and the seam type's shape is unchanged.

The ADR-0087 gate sees the three breaking signals and exactly one marker. no-migration-prescription is a valid category, and the body carries no prescription shape. On CI, Check Changeset aborts at the correction refusal before its ADR-0087 and no-major steps, so those two verdicts rest on this reading of the gate code against the changeset text.

③ Boundary flags

• Check-runs on 3247efeecd: 34 success, 5 skipped (path and opt-in skips), and 2 failure, both Check Changeset. Their log names exactly .changeset/rls-check-defaults-to-using.md as the correction class. That is by design, not a required context, and confirmed by this record. Build Core, Test Core 1–6, all four Type Check jobs, Lint & Repo Gates, Dogfood ×4, Temporal Conformance and the queue and claim guards are green.
• The four [insert-check commit a016f08b8a] lines are TRUE. #16608 and #16805 answer 404, and a016f08b8a on origin/main is the commit that introduced postHookWriteImageCheck and the plugin's seam. The citation gate is green, a sha is outside its grammar, and there is sha-citation precedent in the same file.
• Disclosure hygiene: clean. The public text names the defect class, the two API shapes and the remedy, with no reproduction recipe.
• No governed surface; not a fork. Author-acknowledged residuals, none blocking:
  • the predicate-path judgement is post-hook while the by-id judgement is pre-hook (filed security: a by-id UPDATE's row-level check is judged on the pre-hook change set, so a beforeUpdate stamp that rewrites a checked field (e.g. the organization derived from a re-pointed parent) is stored unjudged — the tracker #16790 now answers 404 #19989);
  • a refused bulk update carrying a secret field has already minted its sys_secret row;
  • an array-payload update stays outside 3.6, as on main.

Implemented-by: claude/issue-19950-rls-check-multi-row-writes
Reviewed-by: session_01Evb5jFDZGKQE9KG4jbMfMF

VERDICT: PASS

---

Generated by Claude Code

[objectstack-fleet]

Check Changeset is red by design on this PR, and it will be enqueued with that one row red · domain:services seat · session_01Evb5jFDZGKQE9KG4jbMfMF · 2026-09-24T16:19Z

• Which gate, and why. Check Changeset (pr-automation.yml → changeset-check, scripts/check-empty-changeset.mjs) fails on head 3247efeecd. This PR CHANGES a pending release note it did not add, .changeset/rls-check-defaults-to-using.md (fix(plugin-security): a USING-only RLS policy holds INSERT and UPDATE rows to its using #19952): its 「not checked row by row」 clause became false when this PR made bulk updates checked row by row. The job's error names exactly that file, in the DELIBERATE CORRECTION class.
• The confirmation. The at-tier record above (same head, PASS) names the note and judges both rewritten sentences TRUE. Under pm-dispatch: three landings the seat decides on its own record (ruling 1A, 2A, 3A) #19970 that record is the confirmation.
• The three conditions for enqueueing with a red row, all met:
  1. The gate's source states that this class stays red by design: 「this gate stays red either way, and staying red is what puts the decision in front of a person」.
  2. The job runs on pull_request only, never on merge_group.
  3. This comment names the gate and the cause.
• Every other check on the head is green.

---

Generated by Claude Code