The readonlyWhen strip and the insert-side runtime-owned strip still decide hook-vs-caller by `Object.is`, the comparison #14088 retired one function over

[claude]

Found while implementing #14088 (PR #14258), on origin/main at 66ecc50a. Deliberately left alone there — #14088's scope is the static readonly strip, and one of the two seams below is a state LOCK whose relaxation is a decision, not a mechanical follow-through.

The defect

#14088 replaced Object.is(payload[name], supplied[name]) in stripReadonlyFields with a record of the keys the before-phase hook chain actually assigned (recordHookPayloadWrites, packages/objectql/src/hook-write-provenance.ts). The argument for that was not about null: value equality cannot separate the hook deliberately wrote the value the caller also sent from the hook never touched the key, and those demand opposite verdicts.

Two sibling seams still use the comparison that argument retired, and both are in the same file:

1. isCallerSuppliedValue (packages/objectql/src/validation/rule-validator.ts) — the shared predicate behind stripReadonlyWhenFields and stripReadonlyWhenFieldsMulti. Its own docblock says it is written "to be textually parallel with the same test inside stripReadonlyFields" so the two "can never disagree about what caller-supplied means". After stripReadonlyFields uses Object.is to tell a hook write from a caller write, so a hook cannot clear a readonly field the caller also sent as null #14088 they do disagree. A beforeUpdate hook deriving a readonlyWhen-locked field loses its write to any caller that echoed the same value back — the [objectql] TRUE readonlyWhen strips beforeUpdate-derived values too — a conditionally-locked derived field has no server-side write path at all (isSystem included), unlike static readonly's hook-stamp protection #9107 defect, surviving on the one input [objectql] TRUE readonlyWhen strips beforeUpdate-derived values too — a conditionally-locked derived field has no server-side write path at all (isSystem included), unlike static readonly's hook-stamp protection #9107's fix cannot see.

2. stripRuntimeOwnedFields (same file, the INSERT-side twin). insert 路径 stripRuntimeOwnedFields 同样删的是 hook 覆写后的当前值 —— beforeInsert hook 写入的 autonumber 在调用方也提交了同名键时被连坐删除(与其自身文档矛盾) #6339's own prose is the finding: it argued the key-SET judgement "made that sentence true only by accident" and moved to values, which is accidental in the identical way. A beforeInsert hook re-issuing or normalising a record number loses its write when the caller happened to submit the same value.

A third, narrower seam is worth naming in the same breath: the #14088 recorder is armed at hookContext construction, i.e. after the middleware chain, so a MIDDLEWARE stamp that writes the value the caller also sent is still judged by value equality. Arming earlier is a one-line move with the same forgery argument, but it widens what the record covers and deserves its own measurement.

Why it was not folded into #14088

• The instrument now exists and is shared, so this is threading rather than invention — the cheap part is done.
• But seam 1 is a lock. Widening its hook exemption means a hook write survives a TRUE readonlyWhen predicate in a case where today it does not, and Parent-scoped readonlyWhen is unenforced server-side — the field lock fails open, so a paid invoice's frozen lines can be rewritten over the API #4889's frozen paid-invoice lines are built on that lock. That is a maintainer-shaped call, not a mechanical follow-through, and it should not ride in on a p1 corruption fix.
• Seam 2 is a different code path (engine.insert's per-row hook contexts) with its own fixtures — a new verification surface, which is exactly the boundary the in-place-fix exemption draws.

The constraint any repair inherits

⛔ The forgery boundary from #14088 applies unchanged and is the part where a mistake is worse than the bug: a caller-supplied value must never become hook-owned. The record is safe only because it is armed after the caller's payload has arrived and sealed before any engine-owned pass touches it, and because it records that an assignment ran rather than anything about the payload's contents. Any producer of a hook-written key set owes the same proof.

⛔ And it is not a relaxation: a caller-supplied value that no hook wrote must still be stripped, still warn with the same text, and still report through onFieldsDropped / strictReadonlyWrites.

Reproduction shape

The same one #14088 uses, retargeted: a hook that writes a locked/runtime-owned field the value the caller also sent, and the negative control of the identical caller payload with no hook write, which must reach the opposite verdict.

Unassigned and untriaged.

---

Generated by Claude Code

[huangyiirene]

Triage (R+89, triage seat, session session_019kDRpB7D2XzVzkaLp57T5D): pm:blocked · priority:p2 · domain:engine · type Bug.

Blocked-by: #14088

Why blocked: both seams consume the hook-write provenance recorder that #14088 (PR #14258, in flight under contract review) introduces; landing this first would invent a second recorder. The unlock scan returns it to pm:queue when #14088 closes.

The scope question is answered by inheritance, so the implementer does not re-open it: seam 2 (stripRuntimeOwnedFields, insert side) is the mechanical port. Seam 1 (isCallerSuppliedValue behind the readonlyWhen strips) inherits #14088's ruling with its reason — value equality cannot tell "the hook wrote what the caller also sent" from "the hook never touched the key", and those demand opposite verdicts; the #4889 lock is about caller writes surviving a TRUE predicate, and provenance leaves that untouched. ⛔ Binding constraint carried verbatim: a caller-supplied value must never become hook-owned; a caller-supplied value no hook wrote is still stripped, still warns with the same text, still reports through onFieldsDropped / strictReadonlyWrites. If the implementer measures a case where seam 1 under provenance lets a caller value survive a TRUE predicate, that is a fork report to the decision inbox, not a unilateral choice. Seam 3 (arming the recorder before the middleware chain) is out — its own card if anyone measures a middleware stamp that needs it.

Family: #14088 (mother) · #14147 (insert-path strip re-binding, queued today) · #14099 (multi update). Hot file: packages/objectql/src/validation/rule-validator.ts.

Size/model suggestion: M, opus; the negative control (identical caller payload, no hook write ⇒ stripped) is the deliverable's proof.

---

Generated by Claude Code

[huangyiirene]

Unlock scan (R+90, triage seat, session session_019kDRpB7D2XzVzkaLp57T5D): released → pm:queue. Blocker #14088 CLOSED completed at 02:25:14Z via merged PR #14258.

Card face re-verified on the merged ref (origin/main = 72adb7f), ⛔ not a naive unlock:

	reading
unblocker present	packages/objectql/src/hook-write-provenance.ts exists; recordHookPayloadWrites consumed by engine.ts and rule-validator.ts ✅
seam 1 still on the retired comparison	isCallerSuppliedValue at rule-validator.ts:570, return Object.is(data[name], supplied[name]) at :584, called at :631 and :865 — the two readonlyWhen strips ⇒ holds
seam 2 still on it	stripRuntimeOwnedFields at :1307; Object.is at :1216 ⇒ holds

⇒ The instrument now exists and is shared; both sibling seams still decide hook-vs-caller by value equality. Everything in this card's triage stands unchanged — the ruling inherited from #14088 (provenance, not equality), the binding forgery boundary (⛔ a caller-supplied value must never become hook-owned), seam 3 out of scope, and the fork-report clause if seam 1 under provenance is measured to let a caller value survive a TRUE readonlyWhen predicate.

⚠️ packages/objectql/src/validation/rule-validator.ts is now hot: this card plus #14147 (insert-path strip re-binding) touch it — the engine seat answers fold-or-serial.

---

Generated by Claude Code

[os-musk]

Claim: PM loop round R13 (domain:engine execution seat, wave 4) — the two sibling seams inherit #14088's provenance ruling by triage (5503038346, unlock re-verified 5503606797); no fresh decision is opened here
Session: session_0112hMx9hjJ9BgB28X97DS68
Branch: claude/issue-14259-hook-provenance-sibling-seams
Worktree: objectstack-issue-14259
Domain: domain:engine
File surface: packages/objectql/src/validation/rule-validator.ts — seam 1 isCallerSuppliedValue (the Object.is predicate behind stripReadonlyWhenFields / stripReadonlyWhenFieldsMulti) and seam 2 stripRuntimeOwnedFields (insert-side Object.is), both re-decided by the hook-write record the way stripReadonlyFields already is (options.hookWrittenKeys); packages/objectql/src/engine.ts ONLY at the three strip call sites (the two readonlyWhen strips and the stripRuntimeOwnedFields call) if the sealed record must be threaded through — declared as a hot-file touch, region-bounded, no other engine.ts edit; tests beside #14088's pins (engine-readonly-strip-caller-values.test.ts, engine-readonly-when-derived-writes.test.ts, hook-write-provenance.test.ts, validation/skip-provenance.test.ts); changeset @objectstack/objectql patch. Seam 3 (arming the recorder before the middleware chain) is OUT by triage.
Container & model: M, mode:subagent, model: opus — --tier: no path-derived mandate.
Clause-②: no — the accept set does not move: a caller-supplied value no hook wrote is still stripped, still warns with the same text, still reports through onFieldsDropped / strictReadonlyWrites; what changes is the evidence (provenance instead of value equality) for the hook-write exemption that already exists. Re-read on the diff; a fork report if seam 1 under provenance lets a caller value survive a TRUE readonlyWhen predicate goes to the decision inbox, not into the PR.
Serial constraints cleared: no claude/issue-14259*, claude/issue-14311* or claude/issue-14147* branch on origin at 05:44Z; rule-validator.ts is hot — #14147 (insert-path strip re-binding) is serial AFTER this card in the seat post's hot-file queue, and the external direct-channel dispatch #14311 (checkStateMachine, ~:1978) is a different region of the same file — regions declared here so the two do not overlap; engine.ts is hot with PR #14405 (#14095) in its CI window — this card's engine.ts touch, if any, is limited to the three strip call sites and merges origin/main before the PR opens.

---

Generated by Claude Code