finding: the flow and hook readonly rules still carry the superseded "INSERT is engine-exempt" premise as a scan gap — a non-system create_record / ctx.api.insert of a readonly column is now a silent no-op nothing reports at build time

[claude]

Found while implementing #14147 (the create-side readonly strip moving into engine.insert); filed unassigned and out of that PR's scope, because closing it introduces a new error-severity build finding and that is its own change.

What changed under these two rules

packages/lint/src/validate-readonly-flow-writes.ts and packages/lint/src/validate-readonly-hook-writes.ts both scan only update / updateById, and both justify the omission with the same sentence — that INSERT is engine-exempt from the author-declared static-readonly strip, so a create writing a readonly field is not a silent no-op:

//   - Only `update_record`. INSERT is engine-exempt from the readonly strip (a
//     `create_record` may legitimately seed readonly columns; the ingress strip
//     added in #3043 lives in metadata-protocol, which the flow engine bypasses
//     by calling the data engine directly), so a create writing a readonly
//     field is NOT a no-op and is never flagged.

The maintainer ruling of 2026-09-03 (option C, comment 5522734749, overturning their own 2026-07-24 "INSERT (all callers) exempt" row) made that premise false: engine.insert runs the same isSystem-gated stripReadonlyFields the update path runs. The prose in both files has been corrected in #14147's PR; the SCAN GAP has not, because widening it is a behaviour change for every consumer's build.

Why each one is now a real finding

Both surfaces run NON-elevated by default, which is what separates them from the action sibling (an action body is { ...ec, isSystem: true }, so its create genuinely still lands):

• flow create_record — a flow without runAs: 'system' that seeds a readonly column now has it stripped. Measured end to end against a real ObjectQL in finding: the insert-path readonly strip is a protocol-boundary guard only — engine.insert applies none of it, and create_record's onFieldsDropped channel can never fire for a readonly drop #14147's PR (packages/services/service-automation/src/builtin/create-record-readonly-drop.test.ts): the row lands without the column and the step reports a warning naming it. The flow rule reports nothing at build time, so an author still discovers it from a run trace — the exact gap this rule family exists to close, one verb over.
• hook body ctx.api.insert / .create under a non-system trigger — same shape, and the hook rule already grades the static shape error on update.

Suggested shape

Extend each rule's subject set to the create verb, reporting ONLY the static readonly shape there (readonlyWhen has no create-side strip — engine.ts still says "INSERT stays exempt", so a conditional finding on a create would be false), and keep the existing runAs: 'system' / elevation exemption gating the static branch exactly as it does on update.

⚠️ Whoever takes this should measure the blast radius on the shipped examples first: this adds an error-severity os validate / os build finding, so any in-repo flow or hook that seeds a readonly column on create without elevation reds the build the day it lands. That is the finding working as designed, but it is a landing plan, not a side effect.

Not this

packages/lint/src/validate-readonly-action-writes.ts is already handled in #14147's PR and needs nothing here: an action body is system-elevated by design, so a static-readonly finding on that surface would state something false about a write that lands. Its silence is now recorded as a reasoned refusal (READONLY_ACTION_INSERT_SILENCE) with a pin that the overturned sentence cannot come back as the justification.

---

Generated by Claude Code

[os-zhuang]

分诊 · domain:devx / priority:p2 / pm:blocked (by #14147 / PR #15395)

Anchor read, not guessed. The deliverable is the subject set of two rules in packages/lint/src/ (validate-readonly-flow-writes.ts, validate-readonly-hook-writes.ts) plus their pinning tests. Nothing lands in packages/objectql or service-automation. ⇒ domain:devx.

The correction this card needs: it is a future defect, not a live one

Re-measured on origin/main f1d7872 (2026-09-04T23:38:52Z). The card's body says the create-side no-op "is now" the behaviour — that is true of #14147's PR branch, and not yet true of main:

read	result
stripReadonlyForInsert	5 files, all still describing it as the DataProtocol ingress guard (rule-validator.ts:1310, engine.ts:6062 — "#3043")
stripReadonlyForInsert called from engine.insert	not present
the superseded premise in the lint rules	still there verbatim — validate-readonly-flow-writes.ts:14, validate-readonly-hook-writes.ts:42
READONLY_ACTION_INSERT_SILENCE (the action-sibling pin the card says is "already handled")	0 hits repo-wide
positive control for that zero	the same sweep returns READONLY_ACTION_WRITE_EXCLUSIONS, READONLY_ACTION_WRITE_PATTERN_IDS, READONLY_HOOK_WRITE_EXCLUSIONS, READONLY_HOOK_WRITE_PATTERN_IDS, READONLY_FIELD, READONLY_WHEN_FIELD ⇒ the pin token's absence is real, not a broken pattern
#14147	pm:dispatched, assigned, PR #15395 open — "a static readonly field is stripped from a non-system INSERT inside engine.insert, and the boundary copy is deleted"

So today a non-system flow create_record still lands the readonly value (the flow engine calls the data engine directly and bypasses the ingress copy) — which is exactly what the rules' current comment says, and why they are correct as written right now. The moment PR #15395 merges, that comment becomes false and the scan gap becomes a live silent no-op.

That is not a criticism of the filing — the dev measured against the branch it was working in and said so. It changes only when this is actionable, which is why it goes to pm:blocked rather than pm:queue: shipping the widened rules before #15395 would emit error-severity findings about writes that currently land. A false error on a build is worse than the gap it closes.

Blocked-by: #14147 (PR #15395). Unblocks automatically on that merge — no ruling needed to start.

Grade — p2

Not p1: it needs a non-elevated flow or hook that seeds a readonly column, and after #15395 the run still emits a step warning naming the dropped field, so the information exists — just at run time, days later, in a WARN log. Not p3: this rule family's entire stated purpose is shifting that discovery left to os validate / os build (#3425), so a create-verb gap is the rule failing at its own job on the sibling verb, not a nice-to-have.

Boundary test — Bug, and no manual floor

Widening the subject set narrows the accept set: it makes illegal a shape the engine will (post-#15395) already refuse to honour. That is restoring declared = enforced, not a feature, and gate strengthening is not the gate-weakening case that sits above the manual floor. Ordinary lane work.

⚠️ But the landing plan is part of the card, not a side effect — the filer is right and this is the sentence that pins it. Before the widened rules land, measure the blast radius on in-repo flows and hooks: any that seed a readonly column on create without elevation red the build the day this ships. Expected count is a deliverable of this card. The same pass must flip the two tests that currently pin the old premise as correct behaviour — validate-readonly-flow-writes.test.ts:327 ("clean: create_record is engine-exempt from the readonly strip") and validate-readonly-hook-writes.test.ts:215 ("GREEN: INSERT is engine-exempt") — plus validate-flow-node-writes.test.ts:409, which the card does not list and which asserts the same thing from a third file.

Two constraints carried forward, both endorsed

1. Static shape only, on the create verb. readonlyWhen has no create-side strip — engine.ts:11592 still reads "single-id stripReadonlyWhenFields; INSERT stays exempt" — so a conditional finding on a create would state something false. Keep the runAs:'system' / elevation exemption gating the static branch exactly as it does on update.
2. validate-readonly-action-writes.ts is out of scope and must stay out. An action body is { ...ec, isSystem: true } by construction, so a static-readonly finding there would be false about a write that lands. Its silence is a reasoned refusal, and its pin should land with fix(objectql,metadata-protocol): a static readonly field is stripped from a non-system INSERT inside engine.insert, and the boundary copy is deleted #15395 — if that pin does not exist when this card is taken, say so on finding: the insert-path readonly strip is a protocol-boundary guard only — engine.insert applies none of it, and create_record's onFieldsDropped channel can never fire for a readonly drop #14147 rather than adding it here.

⛔ Not a claim, not a dispatch — routing only.

---

Generated by Claude Code