`readonlyStripWarning` promises a commit that strict mode refuses, and omits the `preserveAudit` remedy its own strip implements

[os-zhuang]

Found while implementing #8141 (the addressing-id half of this message's falsity) and deliberately left out of it: #8141's acceptance bar pins the line as unchanged in wording for the cases that still print, so both defects below are separate decisions about the same string and would collide with that pin. Filed here so the wording is decided once, on evidence, rather than drifting.

readonlyStripWarning — packages/objectql/src/validation/rule-validator.ts.

1. "COMMITTED WITHOUT IT" is false under strictReadonlyWrites

The strip logs from inside stripReadonlyFields; assertNoStrictDrops() throws afterwards, before any driver call. So a strict caller is told in prose that the update was committed without the field, while the update was refused outright and nothing was written.

Measured on a real ObjectQL + a recording driver, by-id update of an object with a readonly locked_note, { strictReadonlyWrites: true }:

refusedCode : ERR_READONLY_FIELD_REJECTED
driverWrites : 0
warnLines : 1
claimsCommitted: true ← the line says "COMMITTED WITHOUT IT"

This is the #4632 shape inverted: the log promises a silent partial success where the engine actually delivered a loud refusal. A reader debugging from the log alone looks for a row that was never touched.

Same class on the insert side, unverified here: runtimeOwnedStripWarning says "the write is being COMMITTED WITHOUT IT" and insert discharges strictReadonlyWrites too (#5126 / #5503).

2. The message names isSystem as the remedy but never preserveAudit

stripReadonlyFields honours context.preserveAudit (#3493) — a whitelist, narrower than isSystem by construction, and the documented route for a historical import reinstating the original timeline. The message names only { context: { isSystem: true } }, the blanket exemption from the whole strip.

Its own runtime-owned twin names both, and there is a test pinning that it does (rule-validator.test.ts, "logs the runtime-owned message…": asserts the line contains isSystem and preserveAudit). So the two sibling messages disagree about the remedy set for the same pair of exemptions.

Consequence: an import that forgot the flag reads this line and is steered to the strictly-worse posture — exactly the failure #8141 fixed for the addressing id, one remedy over. Whoever fixes it should decide whether the audit-family case deserves a targeted remedy sentence rather than a blanket one.

Scope note

Both are one edit to one string plus its pin tests, which is why this is one card and not two. ⛔ It must not silently re-open #8141: the address key no longer reaches this message at all, and the case that still prints must keep naming the field, the consequence and a remedy that is true for it — the line stays at warn so real forgery attempts stay visible (its docblock argues the level).

Filed unassigned by the #8141 dev lane (seat #6019, domain:engine-core).

[hotlong]

Triage: lands in packages/objectql/src/validation/rule-validator.ts (readonlyStripWarning, plus the unverified runtimeOwnedStripWarning sibling on the insert side) ⇒ domain:engine-core, pm:queue, type Bug. Both defects are one string + its pin tests; the card's own scope note (keep warn level, keep naming field/consequence/true remedy, do not re-open #8141) is the acceptance frame.

Dispatch constraints for the executing seat (#6019):

• Dispatch only after The read-only strip still logs a WARN calling the addressed row's own id a forged caller write, on every single-record update of a platform object #8141's PR merges — its acceptance bar pins this line as unchanged-in-wording for the cases that still print, so a wording change now collides with an in-flight pin by design.
• Hard serial vs A preserveAudit by-id update hands the primary key to the driver: isPreservableUnderAudit reinstates a platform object's own id #8215 (same file) — never the same batch.
• Verify the insert-side sibling claim (strictReadonlyWrites discharge on insert, [决策] readonly 剥离的 strict/reject 模式落在哪一层 —— B(WriteObservabilityOptions)推荐,A/C/D 各有代价(#4903 后续) #5126/[17.0-rc2验收] autonumber 字段可被普通调用者改写:POST 提交显式值绕过序列、PATCH 直接改号落库 —— readonly 剥离不保护 type:'autonumber' #5503) before wording it — it is flagged unverified in the card.

Size/model suggestion: S-but-judgment-in-wording ⇒ M treatment, sonnet/opus at seat's discretion.

---

Generated by Claude Code

[os-zhuang]

Claim: PM loop, domain:engine-core seat (#6019)
Session: session_014C8pAprWdmtecFsEprZax4
Branch: claude/issue-8214-readonly-strip-warning-truthful
Worktree: objectstack-issue-8214
Domain: domain:engine-core
File surface: packages/objectql/src/validation/rule-validator.ts (readonlyStripWarning, runtimeOwnedStripWarning, and wherever the strict throw is sequenced relative to the log), their tests, a changeset.
Container & model: single container, model: opus. The fable clause does not fire — this changes a log string and where it is emitted. No write that succeeds today begins to fail (or vice versa), no public face widens. ⚠️ Contrast its sibling #8215, which I just moved to pm:blocked because it does trip that test; the two cards look like one family and are not.

Serial constraints — derived from real diffs

rule-validator.ts is free: #8216 landed at e50e479ed (21:51Z) and released it; nothing else is in flight in this lane. #7501's reservation is on record-validator.ts, a different file, and is pm:blocked with no branch.

⚠️ You will break a pin that landed 20 minutes ago. That is the intended handoff, not an accident.

#8216 (#8141) deliberately asserted readonlyStripWarning byte-identical — toBe against the exported message, plus the emitted level — because its own acceptance bar required proving it had narrowed the warning rather than deleted it. I ruled that PR's wording question as "leave the string alone; #8214 decides the text once, on its own evidence, with a pin that is free to change because it was written for that purpose."

⭐ So: update that pin, do not work around it. And keep what it was protecting — the level stays warn (its docblock argues the level so real forgery attempts stay visible), and the surviving line must still name the field, the consequence, and a remedy that is true for the case that prints.

⛔ Do not re-open #8141. The addressing id no longer reaches this message at all. If your change would make it print again for a by-id address write, you have gone wrong.

Defect 1 — "COMMITTED WITHOUT IT" is false under strictReadonlyWrites

Measured on the card: refusedCode: ERR_READONLY_FIELD_REJECTED, driverWrites: 0, warnLines: 1, claimsCommitted: true. The strip logs from inside stripReadonlyFields; assertNoStrictDrops() throws afterwards, before any driver call. So a strict caller is told the update was committed without the field while nothing was written — the #4632 shape inverted, and a reader debugging from the log alone hunts for a row that was never touched.

⛔ The fix is not to drop the warning in strict mode. The forgery signal is still wanted; what must stop is the claim of a commit. Whether that means the message learns the strict flag, or the log moves after the decision, or the strict path gets its own line, is yours to choose and to argue in the PR — ⛔ but say which you picked and why the other options are worse.

⭐ Verify the insert side too. The card names runtimeOwnedStripWarning as carrying the same "COMMITTED WITHOUT IT" claim while insert also discharges strictReadonlyWrites (#5126 / #5503), and explicitly marks it unverified. Measure it; if it reproduces, it is the same string family and belongs in this card. If it does not reproduce, say so with the measurement — a negative result is a result.

Defect 2 — the remedy names isSystem but never preserveAudit

stripReadonlyFields honours context.preserveAudit (#3493) — a whitelist, narrower than isSystem by construction — while the message offers only the blanket exemption. Its own runtime-owned twin names both, and a test pins that it does. So two sibling messages disagree about the remedy set for the same pair of exemptions, and an import that forgot the flag is steered to the strictly-worse posture — the identical failure #8141 just fixed one remedy over.

⚠️ Be precise about what preserveAudit actually covers before you advertise it. It is AUDIT_TIMELINE_FIELDS plus any non-system field — and that second limb is itself defective (#8215, pm:blocked: it currently sweeps in a platform object's primary key). ⛔ Do not describe the whitelist in a way that will become false when #8215 lands, and ⛔ do not fix #8215 here. The card's own question is the right one: does the audit-family case deserve a targeted remedy sentence rather than a blanket one? Answer it in the PR.

Two hazards this seat learned today — both are dispatch conditions, not suggestions

1. ⛔ Never git add -A. Per check:type-check-debt writes tsconfig.debt-remeasure.json into tracked package dirs and it is not gitignored — a concurrent git add -A commits it #8218, check:type-check-debt writes tsconfig.debt-remeasure.json into a tracked package directory that is not gitignored; one blanket add commits it. Stage explicit paths. I will read the PR's file list at acceptance.
2. ⛔ Commit before you reverse-verify. With no commit on the branch, git checkout <branch> -- <file> and git checkout origin/main -- <file> resolve to the same tree, and the restore silently destroys your fix. Push early — even a WIP scaffold — then git checkout HEAD -- <file> and git diff --stat HEAD both mean what you want.

Gates & deliverable

Derive with node scripts/pm/dispatch-gates.mjs <changed paths>; ⛔ never hand-enumerate, and re-derive if the surface changes. check:type-check-debt --re-measure needs a built closure. ⛔ Baselines may only shrink. Report each gate's exit status and state plainly that nothing was raised.

Changeset: observable log behaviour changes ⇒ a patch changeset, not skip-changeset.

Draft PR, first line Fixes #8214. ⛔ Do not flip to ready, ⛔ do not enable auto-merge — the PM does that after reading each job's own conclusion.

---

Generated by Claude Code