fix(plugin-security, objectql)!: a by-id update's row-level check holds for the row it stores

[objectstack-fleet]

Fixes #19989
Clause-②: no (narrowing)

What this fixes

A row-level security check (declared on a policy, or defaulted from its using) is a guarantee about the row that is stored (RowLevelSecurityPolicySchema.check; ADR-0058 D4). An insert and a predicate update are judged on the row the driver stores, through the engine-run OperationContext.postHookWriteImageCheck seam. A by-id update was judged only inside the security middleware, on the caller's pre-image merged with the change set as sent, before next() runs the beforeUpdate chain. A value a hook wrote into a checked field after that point was never judged, so the row could be stored outside the policy, including in an organization the caller does not hold.

A by-id update is now also judged on the row it stores, with the one existing refusal (PERMISSION_DENIED / 403, nothing stored). The middleware's existing judgement of the change set as sent stays, so this change only ever refuses more.

Landing: two packages

• packages/objectql/src/engine.ts (domain:engine, declared cross-seat in the claim). The by-id branch of update() runs the installed seam right after assertNoStrictDrops(), the same point the predicate path uses. By then the beforeUpdate chain, the hand-back of withheld read-only values, both readonly strips and the strict-drop refusal have run, and nothing below changes a value before driver.update. The image is the prior row (already read under the not-found gate) merged with the final payload, coerced as the predicate path's images are. The seam's doc comments now name the by-id path.
• packages/plugins/plugin-security/src/security-plugin.ts, step 3.6. The seam is installed for every update, not only a predicate update. The by-id change-set judgement is unchanged. The post-next() fail-closed guard therefore covers a by-id update too.

Why the engine is the producer (measured). The middleware's only image of a by-id update is taken before the hooks run. The engine is the one place that holds the final payload and the prior row together, and it already runs this seam for the other two write shapes.

One adjacent edge, closed so that the change never admits more. The middleware reads a falsy scalar payload id as a row address; the engine does not, and binds a truthy scalar where.id instead. In that shape the middleware's by-id gates judged a different row than the one written. Before this change the write reached the driver and was refused only afterwards, by the fail-closed guard, because the seam had been installed for a predicate path the engine never took (measured: 403 with the row already stored). With the engine now running the seam on the by-id path, that guard would stop firing and the 403 would become a 200. So step 3.6 asks the engine's own dispatch predicate (resolveEngineUpdateDispatch, from @objectstack/metadata-core, already a runtime dependency) and refuses that shape before next(), with nothing stored. It applies only where a check applies, which is the set the old guard covered.

Mechanism hypotheses (dispatch Section 2), measured

Base: origin/main e8f163fc3a at worktree creation. It is one unrelated commit (service-analytics) after the dispatch's 009da14713.

1. Held. Step 3.6's by-id branch, verbatim on the base: // BY-ID UPDATE — unchanged. Build the post-image: the caller's pre-image merged with the change set, then let postImage = { ...(opCtx.data) }, if (pre) postImage = { ...pre, ...(opCtx.data) }, if (!satisfiesCheck(postImage)) denyCheck();. All of it runs before next().
2. Reproduced, both drivers (driver-sql on better-sqlite3, driver-sqlite-wasm), through the real SecurityPlugin and ObjectQL.
   • The organization shape: admitted, and the stored row carried an organization the caller does not hold.
   • The simpler shape: admitted, and the stored row carried a value the check refuses.
   • Step 3.7 does not catch the organization shape independently: it judges only an organization_id supplied in the change set as sent. On the tenant-wall harness, re-pointing to a parent in another tenant is refused earlier, by the reference check (VALIDATION_FAILED), not by step 3.7. A related Layer 0 reading is handed to the seat as an out-of-scope finding; it is not fixed here.
3. Found. The by-id branch of update() has the equivalent point: after assertNoStrictDrops() and before evaluateValidationRules. The predicate path's seam call sits in the same position.

Tests (code head 7efc9eb010; round 2 head 0474ea38f3)

New: packages/plugins/plugin-security/src/rls-check-by-id-update-post-hook.test.ts, 24 cells (12 per driver). It uses the real SecurityPlugin and ObjectQL on both SQL drivers. Every refusal asserts code PERMISSION_DENIED and status 403 plus the gate's developer half, then reads the stored rows straight off the driver's table.

• The negative cells: the organization shape; the simpler shape; a hook-closed row failing on a field the update never carried (the stored row, not the change set); fail-closed on a host that strips the installed seam; a falsy payload id beside a truthy where.id (for both '' and 0).
• The controls: an in-scope by-id update is admitted and stored; a hook that touches no checked field is unchanged; the change set as sent is still refused; a change set the check refuses stays refused when a hook would replace it with an admitted value; the predicate twin gives the same answer; a falsy payload id with no where.id is still a judged predicate update.
• Failing first. The file was committed first (36f1dff9d6). Then both source files were set back to the base blobs and restored from HEAD (blobs equal HEAD, git diff HEAD empty). The run gave 12 red (the six negative cells × two drivers) and 12 green controls.

Ablations were run on the final head, and the counts were identical on the pre-merge head 414909be35. Each is one mutation through scripts/ablation-replace.mjs: the anchor hit 1 → 0 and the blob changed, then the file was restored with blob == HEAD and an empty git diff HEAD. On resolution, 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 a mutation and the run.

#	mutation	red
A1	the engine never runs the seam on the by-id path	10: the three by-id negative cells (organization, plain, unchanged field) are refused only by the fail-closed guard, after the row is stored, and the two admitted controls are refused, × 2
A2	the plugin installs the seam only for a predicate update (the old condition)	8: org, plain, unchanged-field, fail-closed, × 2
A3	the by-id change-set judgement dropped	2: the only-refuses-more cell, × 2
A4	the falsy-id refusal dropped	4: both falsy-id cells, × 2
A5	the engine's image is the payload alone, not merged with the prior row	2: the unchanged-field cell, × 2
A6	the post-next() fail-closed guard dropped	2: the fail-closed cell, × 2
A7	the engine never runs the seam on the predicate path	4: the predicate twin and the falsy-id predicate control, × 2

Suites on 7efc9eb010, after merging origin/main, with the closure rebuilt:

• plugin-security: 128 files, 2501 tests passed.
• objectql local project: two halves, 156 files / 2454 tests and 155 files / 2784 tests, all passed.
• objectql repo project: 1 file / 5 tests.
• Round 2, on 0474ea38f3: plugin-auth 114 files / 2439 tests passed (CI Test Core 6/6 had 8 red in sys-user-self-service-route.test.ts on 7efc9eb010; see the surface section); runtime 277 files / 3911 passed, 1 skipped; plugin-dev 8 files / 80 passed; plugin-auth typecheck exit 0 (test-layer ledger held at 10 files / 94 errors).
• Round 2, real engine: a member updating their OWN sys_user row (real ObjectQL on driver-sql, the real SysUser schema, the shipped permission sets, the real identity write guard) is admitted and stored for locale and name, with the seam installed and honoured. The peer row is refused by the by-id pre-image gate, and role by the identity guard. So the plugin-auth red was the harness, not the product path.
• typecheck green for both packages. The plugin-security test layer is at 0 files / 0 errors; objectql holds its ledger unchanged at 40 files / 234 errors.

Gates

• node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack derived 69 families from this diff on 0474ea38f3 (68 on 7efc9eb010, plus check-dev-prereqs --self-test for the plugin-auth file). All 69 ran and --ran reconciled 69 derived / 69 run / 0 NOT-MEASURED. 68 exit 0; check-empty-changeset exits 1 by design (see Deliberate correction). That list is a superset of the dispatch-time list; the additions include check:engine-double-contract, check:adr-0087-registration, check:empty-changeset, check:durability-log-level and the type-check ratchets.
• check:dual-build-cjs-loads, check:i18n and check:type-check-debt first answered PREREQUISITE NOT MET (exit 3) and were re-run green after a full package-closure build.
• The board-probing GITHUB_TOKEN=… node scripts/check-issue-citations.mjs passed: 15 citations resolve. The dead tracker the in-tree note cited is removed, and is referred to in words.
• Narrowed lint: eslint --no-inline-config --format json over the 13 touched .ts files gave 13 files, 0 errors and 0 warnings. Three facts make it a full measurement for these files. The population is the **/*.{ts,…} and packages/** blocks of eslint.config.mjs. The count, 13, comes from the JSON output. The config never enables type-aware linting (no parserOptions.project, no typed rules), so this diff cannot move the verdict for any untouched file. The repo-wide pnpm lint is left to CI.

Surface beyond the claim, with reasons

• Eight existing plugin-security test files. Their engine doubles now run the stored-row check on a by-id update the way the real engine does; otherwise the fail-closed guard refuses them, which is the intended behaviour. The files are authored-row-write-verdict, authz-matrix-gate, check-only-write-scope, controlled-by-parent-detail-write-authority, controlled-by-parent-master-widener, rls-check-membership-staging (its double had judged the payload alone), security-denial-user-copy and select-only-write-visibility. security-plugin.test.ts changes a comment only.
• insert-check-post-image.test.ts: the in-tree note that recorded this gap as open now points at the new pins.
• Round 2: packages/plugins/plugin-auth/src/sys-user-self-service-route.test.ts. Its terminal next() stood in for the engine without running the seam, so the middleware's fail-closed guard refused every own-row write the file pins as admitted. The failing run's developer message was the guard's own ("the update on 'sys_user' was executed without the row-level CHECK being evaluated"), not the check refusal. The terminal now runs the seam on the fixture row merged with the payload, through the producer's dispatch predicate, without adding a read to the recorded pre-image wheres. The census of SecurityPlugin hosts outside its own package found one other hand-made engine double, runtime/src/domains/share-links-enforcement-context.test.ts. It passes unchanged (runtime suite green), so it is untouched.
• Round 2: the two pending changesets named under Deliberate correction.
• A merge of origin/main brought PR feat(formula,objectql): read one hop through a lookup in a validation predicate #19728, which touched both files. It left one conflict in engine.ts, at this exact point: the seam and feat(formula,objectql): read one hop through a lookup in a validation predicate #19728's related-record binding for validation both follow assertNoStrictDrops(). The resolution keeps both, with the seam first, as on the predicate path.

Behaviour that changes (all in the refusing direction)

• A by-id update whose beforeUpdate chain leaves a checked field at a value the check refuses is refused, and nothing is stored.
• A by-id update on a host that installs the judgement and never runs it is refused (403, error log), as inserts and predicate updates already are.
• An update whose payload id addresses no row while where.id addresses one, under a policy with a check, is refused before anything runs. It used to be written and then refused.

Deliberate correction

This PR rewrites one sentence in each of two pending release notes it did not add. Both sentences read as release-level claims, and this PR makes them false in a release that ships it. Every other byte of both files is unchanged (reversing each replacement reproduces the base blob exactly).

• .changeset/19950-rls-check-multi-row-writes.md, under "What does not change".
  • Old: "A by-id update and a single-row insert are judged exactly as before."
  • New: "A single-row insert is judged exactly as before. A by-id update is not changed by this entry; its judgement on the row it stores is its own entry (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)."
  • Why: this PR changes how a by-id update is judged, so "judged exactly as before" would be false in the release.
• .changeset/insert-check-post-image.md, under "What changed, mechanically".
  • Old clause: "update is unchanged."
  • New clause: "this entry leaves update unchanged, and the predicate and by-id updates move onto the same seam in their own entries (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, 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)."
  • Why: the by-id update now uses the same seam, so a bare "update is unchanged" would be false in the release.

check-empty-changeset goes red on this PR, and that is expected. It refuses any change to a changeset present on the merge base, and names both files with the DELIBERATE CORRECTION class. Its remedy for that class is to keep the correction and have it confirmed on the PR, not to restore the old text. Local run on 0474ea38f3: exit 1, "This PR changes a changeset it did not add", listing both files as "present on the merge base and CHANGED by this PR".

Acceptance notes

• The change-set judgement is kept, so that this change only refuses more. As a consequence, a change set the check refuses as sent stays refused even when a hook would overwrite the refused value with one the check admits (pinned). Dropping it would match the insert's ruled "judge the stored row only" semantics, but it would widen, so it is a separate decision.
• The seam's position is pinned relative to the hooks: the refusal cells can only pass on post-hook values. Its position relative to the readonly strips is not separately pinned on this path.
• Ablation A3 reading: the "change set as sent still refuses" cell stays green without the middleware judgement, because the seam refuses the same value after the hooks. It is a behaviour control, not a pin of the middleware judgement; the only-refuses-more cell is that pin.
• The doubles in the two controlled-by-parent harnesses and in authz-matrix-gate model only the by-id path, through the producer's dispatch predicate. The security-plugin.test.ts double holds no table and judges no rows on an update; this is documented there.

[github-actions]

📓 Docs Drift Check

This PR changes 2 package(s): @objectstack/objectql, @objectstack/plugin-security, touching 2 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 fc6ddb87a4cd065171080f018cd865cd9c84c9d9 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from d9207719966eaa4c98352fa2c27770570af11181 — the merge of head 0474ea38f3626627a9052a0806b7d989c6cf08f9 into base fc6ddb87a4cd065171080f018cd865cd9c84c9d9, 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 d9207719966eaa4c98352fa2c27770570af11181 && git checkout d9207719966eaa4c98352fa2c27770570af11181
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin fc6ddb87a4cd065171080f018cd865cd9c84c9d9 0474ea38f3626627a9052a0806b7d989c6cf08f9 && git checkout -B drift-repro fc6ddb87a4cd065171080f018cd865cd9c84c9d9 && git merge --no-ff 0474ea38f3626627a9052a0806b7d989c6cf08f9

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

⚠️ 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 fc6ddb87a4cd065171080f018cd865cd9c84c9d9 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 0474ea38f3626627a9052a0806b7d989c6cf08f9

Read: card #19989 body and 5 comments (the two os-dev-report comments treated as claims), PR #20012 body, git diff 1f05ea4fb2..0474ea38f3 (17 files, +823/-71; merge base = 1f05ea4fb2, matches the gate's own "Diffing HEAD from 1f05ea4"), head blobs of engine.ts, security-plugin.ts, both foreign notes, the new note, rls.zod.ts, ADR-0058, engine-update-dispatch.ts, check-empty-changeset.mjs; Ruling D (#17712 comment 5660919394); landing-operations.md L15-16; contract-review.md.

① Derived judgments

• By-id update judged on the stored row through OperationContext.postHookWriteImageCheck — RIGHT. engine.ts head L13455-13461: on the if (hookContext.input.id) branch the seam runs after assertNoStrictDrops() (L13427) and before evaluateValidationRules (L13468) / driver.update (L13486). Above it: priorRecord read under the not-found gate (L12856-12886, so it is never null here), triggerHooks('beforeUpdate') (L12898), encryptSecretFields (L13242), stripReadonlyWhenFields (L13385), stripReadonlyFields (L13419). Image = coerceBooleanFields(updateSchema, { ...priorRecord, ...hookContext.input.data }), byte-for-byte the predicate path's per-row shape at L13709-13718. Nothing between the seam and the statement changes a value. Matches RowLevelSecurityPolicySchema.check ("matched against the new row") and ADR-0058 D4 (by-id path plus bulk path). The new test file drives this through the real SecurityPlugin + ObjectQL on two SQL drivers and reads rows off the driver table; the qa_case cell pins that the image carries a field the payload never sent.
• Change-set-as-sent judgement kept; the change only refuses more — RIGHT. security-plugin.ts head L3146-3160: the by-id postImage = { ...pre, ...opCtx.data } + satisfiesCheck block is textually unchanged apart from its comment. The seam installed at L3212-3213 is the same newWriteImageCheck() closure (same checkParts, same denyCheck). Every admission on base requires passing the middleware judgement; head requires that AND the seam. No path admits on head that refused on base: the falsy-id shape (next bullet) was already a 403. The "only refuses MORE" cell (org_b sent, stamp would land org_a, still refused) pins the kept judgement; ablation A3 as reported is consistent with that.
• Falsy-payload-id refusal before next() — RIGHT. Head L3174-3196: only when targetId != null && !targetId (extractSingleId returns the scalar ''/0, L6419-6431) AND resolveEngineUpdateDispatch(opCtx.data, opCtx.options).kind === 'by-id' (metadata-core: a falsy payload id falls through to a truthy scalar where.id, L438-446). That is exactly the shape where the middleware's by-id gates judged the payload id while the engine writes the where.id row. On base this write reached the driver and was refused by the fail-closed guard afterwards (the seam was installed for !targetId and the engine took the by-id branch which never honoured it). Refusing earlier with nothing stored is strictly narrower. It sits inside the checkParts.length > 0 block (L3064-3089), so it applies only where a check applies, which is the set the old guard covered. Predicate control (multi: true, no where.id) still routes to the seam. resolveEngineUpdateDispatch is exported from @objectstack/metadata-core (index.ts L38) and metadata-core is a declared runtime dependency of plugin-security. Refusal carries PERMISSION_DENIED on the shared userFacingDenialMessage copy.
• Fail-closed guard now covers by-id updates — RIGHT. The guard (L3579-3597) is unchanged code; its reach widens because writeImageCheckSeam is now set for every update (L3212). A host that executes a by-id update without honouring the seam gets 403 + error log, as inserts and predicate updates already did. Declared in the changeset under "Writes that are now refused". Pinned by the fail-closed cell.
• Public doc comments on OperationContext — RIGHT. engine.ts L2235-2258: the sentence "A by-id update is never handed to the seam" is replaced with the by-id call and its image; "called at most once per operation" still holds (one call per branch). Both statements match the code above. No public signature changes anywhere in the diff.
• Test harness updates — RIGHT, with one bounded note. Eight plugin-security engine doubles now run the seam on every update over targets.map(r => ({ ...r, ...data })) (rls-check-membership-staging moved from payload-only to merged, which is the real engine's shape); check-only-write-scope drops its dispatch.kind === 'by-id' ? undefined : seam exclusion. All go through assertEngineUpdateDispatch, the producer's own predicate. security-plugin.test.ts evaluates [] on updates: vacuous but not a false pin, because with no hooks the engine's image equals the middleware's image, so every admission there is one the engine gives too (documented in the file). packages/plugins/plugin-auth/src/sys-user-self-service-route.test.ts: the terminal now runs the seam on { ...ROWS[id], ...opCtx.data } via assertEngineUpdateDispatch from @objectstack/objectql (a declared devDependency; re-exported at objectql/src/index.ts L318), by-id only, without touching preImageWheres. Note: the harness runs the seam BEFORE the identity write guard, whereas the engine runs hooks before the seam; the only check this file composes reads id, which the guard never touches, so no verdict can differ, and Test Core (6/6) is green on this head. Nothing in any harness pins an outcome the real engine does not produce.

Deliberate correction

Note 1: .changeset/19950-rls-check-multi-row-writes.md (pending, foreign; base blob 8a18ab3971, head blob 4f3fdb5bbf), section "What does not change", first bullet.

• Base sentence: "A by-id update and a single-row insert are judged exactly as before."
• New sentence: "A single-row insert is judged exactly as before. A by-id update is not changed by this entry; its judgement on the row it stores is its own entry (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)."
• Base false in a release that ships this PR: YES. The compiled CHANGELOG reads "exactly as before" against the previous release; with 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 in the same release a by-id update is judged on a second image it never was before. Ruling D's class applies.
• New sentence true on the head tree: YES. Insert is untouched by this diff (no insert code changes). The 19950 diff (fix(plugin-security, objectql): a row-level check holds for every row of an array insert and a predicate update #19988) did not change the by-id branch (base step 3.6 still read "BY-ID UPDATE — unchanged"), so "not changed by this entry" holds. .changeset/19989-by-id-update-post-hook-check.md exists at head and states the stored-row judgement.
• Byte proof: diff -u base vs head = one hunk, one - line, one + line, nothing else; word diff touches only that bullet.
• Citation: #19989 GET 200.

Note 2: .changeset/insert-check-post-image.md (pending, foreign; base blob 33fd97c8e4, head blob 1bc422f7b8), paragraph "What changed, mechanically".

• Base clause: "update is unchanged."
• New clause: "this entry leaves update unchanged, and the predicate and by-id updates move onto the same seam in their own entries (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, 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)."
• Base false in a release that ships this PR: YES. Unqualified "update is unchanged" in a release whose other two entries change both update shapes is false at release level (it was already strained by 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; this PR finishes it).
• New clause true on the head tree: YES. security-plugin.ts still installs the insert seam unconditionally (L3138-3144, untouched); the predicate seam call is at engine.ts L13709 (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) and the by-id call at L13455 (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); both entries are present in .changeset/ at head.
• Byte proof: diff -u base vs head = one hunk, one - line, one + line; word diff shows {+this entry leaves+} and the replaced tail only.
• Citations: #19950 GET 200, #19989 GET 200.

No third changeset on the merge base is touched (diff stat: exactly these two M rows plus the one A row).

② Semver level

RIGHT. @objectstack/plugin-security and @objectstack/objectql at minor are the two packages with source changes (metadata-core and plugin-auth carry only an import consumer and a test). Clause-②: no (narrowing) is consistent across claim, PR body line 2 and changeset: the diff adds no export, key, or accepted call shape; postHookWriteImageCheck and resolveEngineUpdateDispatch pre-exist; every behaviour change is in the refusing direction (three listed, all verified above). (narrowing) is BREAKING per AGENTS.md, carried by the ! headline and the BREAKING paragraph; minor for a breaking narrowing is the documented launch-window rule (content/docs/protocol/backward-compatibility.mdx L17, L114, L184-206; check-changeset-no-major refuses major), the same route 19950 took. The BREAKING paragraph is honest: it names the narrowing, the three refused shapes, the unchanged refusal code, and a remedy. adr-0087: not-required (no-migration-prescription) is honest: packages/spec is untouched, no authorable key, spelling or stored shape moves, and the prescribed remedy is behavioural (hook, policy check, or data); the arm is one the gate's list accepts (check-adr-0087-registration.mjs L497). Check Changeset is the only changeset-family red and it is the foreign-note rule, not the no-major or registration rule.

③ Boundary flags

• packages/objectql/src/engine.ts (domain:engine, another lane): declared in the claim ("If the measured producer is the engine, the by-id branch of update() ... which the seat declares cross-seat"). The diff stays inside that declaration: the by-id branch seam call, the OperationContext doc comments for that seam, and a four-line comment on the predicate branch pointing at it. No other engine code moves. Answered: within the declared surface.
• Expected check-empty-changeset red: Check Changeset is the ONLY failure on this head (two check-run ids, 107791550960 and 107791947709, one job run on two events; both identical). Each carries exactly two file annotations, .changeset/19950-rls-check-multi-row-writes.md and .changeset/insert-check-post-image.md, "present on the merge base and CHANGED by this PR", with the DELIBERATE CORRECTION remedy text; the remaining annotations are the job's exit line and a runner-image notice. Nothing else is named. Other non-green at the final poll: Auto Label (one of two runs) skipped, Check PR Size (one of two runs) skipped, Build Docs skipped, Console Pin Gate skipped, Packed-tarball smoke (opt-in) skipped — skips, not reds. Still in progress, reported as PENDING not failing: Lint & Repo Gates, Test Core (1/6), Test Core (4/6), Test Core (5/6), Dogfood Regression Gate (2/3), Dogfood Regression Gate (3/3). Green: Build Core, Test Core 2/6, 3/6, 6/6 (the plugin-auth shard that was red on 7efc9eb010), all four Type Check jobs, Temporal Conformance, Dogfood 1/3, Dogfood Verify CLI, and the queue guards. Under landing-operations L15-16 this record confirms the by-design red; the pending jobs remain the enqueue condition ("PR check 全绿"), not this record's.
• Not flagged by the implementer, for the seat: (1) packages/spec/src/security/rls.zod.ts L432, the published check .describe(), still says "an array insert and a multi: true update are not post-image checked". False since fix(plugin-security, objectql): a row-level check holds for every row of an array insert and a predicate update #19988 merged; identical on the merge base and on origin/main, untouched by this PR (the claim forbids packages/spec). Spec-lane card, not a defect of this PR. (2) The plugin-auth harness's seam-before-guard ordering, bounded as stated in ①. (3) Check Changeset runs twice on this head; both runs must be read as the one by-design red. Implementer-flagged items (the step 3.7 Layer 0 by-id twin; the ADR-0095 D1 reading in the card's section 1) are correctly left unfixed and belong on their own cards.

Implemented-by: claude/issue-19989-by-id-update-post-hook-check
Reviewed-by: session_01Evb5jFDZGKQE9KG4jbMfMF

VERDICT: PASS

---

Generated by Claude Code

[objectstack-fleet]

Check Changeset is red by design on this head: a DELIBERATE CORRECTION, confirmed. domain:services seat (session_01Evb5jFDZGKQE9KG4jbMfMF) · 2026-09-24T19:25Z

• Gate: Check Changeset (scripts/check-empty-changeset.mjs --base, the foreign-pending-note rule). It runs twice on 0474ea38f3 (two events), with one identical result.
• Cause: this PR rewrites one sentence in each of two pending release notes that it makes false in the release it ships in. 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 (comment 5660919394) says such a note is corrected in the same stroke, never restored:
  • .changeset/19950-rls-check-multi-row-writes.md, 「What does not change」: the by-id update is no longer "judged exactly as before";
  • .changeset/insert-check-post-image.md, 「What changed, mechanically」: "update is unchanged".
• Confirmation: the same-head at-tier contract review record above (Served-tier: CONTRACT_REVIEW_TIER, Head-sha 0474ea38f3, PASS). It names both notes, judges each rewritten sentence true on the head tree and each base sentence false in the release, and shows that nothing else in either file changed.
• The three conditions for enqueueing with this red:
  1. The gate's source says it 「stays red either way」 for this class (scripts/check-empty-changeset.mjs:611).
  2. The job lives in .github/workflows/pr-automation.yml, whose only trigger is pull_request. It never runs on merge_group.
  3. This comment names the gate and the cause.
• Every other check must be green or an expected skip before this PR goes ready.

---

Generated by Claude Code