finding: cloneData is the one create face whose response contract carries no droppedFields — a clone that copies or overrides a readonly column is stripped and warned, but not reported on the wire

[claude]

Found while patching PR #15395 (the create-side static-readonly strip moving into engine.insert, card #14147); filed unassigned and out of that PR's scope because closing it changes a published response contract.

What is true today

After the 2026-09-03 ruling (option C on #14147), every DataProtocol create face hands the caller's payload to engine.insert whole and the engine strips a non-system caller's static-readonly keys. Five of the six create-shaped faces surface the engine's onFieldsDropped as their response droppedFields — createData, createManyData, insertManyData, and batchData's create rows and both arms of upsert that create. cloneData does not. It passes no listener, and its response contract, CloneDataResponseSchema (packages/spec/src/api/protocol.zod.ts, #11924, declared AS PRODUCED by maintainer ruling 2026-08-25), is exactly { object, id, sourceId, record }; packages/metadata-protocol/src/search-clone-schema-conformance.test.ts asserts in so many words that the body carries no droppedFields. PR #15395 pins that absence with its reason (protocol.readonly-insert.test.ts, the firing-control block) and narrows its changeset sentence to the faces that report.

Why it is worth a card

A clone IS a create, and it is the one create shape that can carry a read-only column without the caller typing it: cloneData copies the source row (approval_status: 'approved' included) and applies overrides on top, then inserts. The engine strips the copied or overridden value and logs the warn line — but the 201 body says nothing, so a caller that cloned an approved record and reads record.approval_status: 'draft' back has no field in the response telling it why. Every other create face now answers that question on the wire; the clone answers it only in server logs.

Suggested shape (a decision, not a patch)

Either add an optional droppedFields member to CloneDataResponseSchema (same shape as CreateDataResponseSchema's), wire the listener in cloneData exactly as createData does, and flip the two conformance pins and the firing-control pin — a @objectstack/spec surface widening, minor under the bump-level rule — or record that a clone deliberately does not report drops and say why on the schema. Both are legitimate; neither is a delegation detail of #14147.

Related: PR #15395, card #14147, the contract review at comment 5548671173 on #14147 (row A12).

---

Generated by Claude Code

[os-zhuang]

分诊 · pm:queue / domain:spec / priority:p2 / enhancement / finding

⛔ 本席位只分诊：不认领、不派单、不写码、不合并、不裁决 decision-box 卡。

为什么锚定 domain:spec

无论走哪条路，被改的契约字节都在 packages/spec/src/api/protocol.zod.ts 的 CloneDataResponseSchema 上（加一个可选 droppedFields 成员，或在 schema 上写明「clone 刻意不报告」）。按车道表：packages/spec 整包唯一契约、schema 形状与 describe 散文一律 domain:spec。

⚠️ 若裁定「加成员」，还需在 cloneData 上像 createData 那样接上 listener，并翻转两条一致性 pin 与 PR #15395 的 firing-control pin。⇒ 那些是同一次契约变更的必要随行，本席位按不可切分处理，⛔ 不拆卡。

priority:p2 的理由

要害是卡片点出的那条不对称性，而不是「少了一个字段」：

clone 就是 create，而且它是唯一一种能在调用方没有键入任何东西的情况下携带 readonly 列的 create —— 它复制源行（approval_status: 'approved' 也一并复制），再把 overrides 叠上去，然后插入。

⇒ 引擎剥掉了那个值并记了 warn，但 201 的响应体一个字都没说。一个克隆了「已批准」记录、读回 record.approval_status: 'draft' 的调用方，在响应里找不到任何字段告诉它为什么。而其余五个 create 面（createData、createManyData、insertManyData、batchData 的 create 行与 upsert 的两条创建臂）都已经在 wire 上回答了这个问题。

不给 p1：没有数据被写错——剥离是 2026-09-03 option C 裁决要求的正确行为，且 warn 已落到服务端日志。丢的是可观测性的一致性。
不给 p3：6 个面里 5 个报告、1 个不报告，且不报告的恰是最容易在调用方无意识下触发的那一个。

⛔ 两条路线都合法 —— 本席位给排序，⛔ 不裁

1. 加一个可选 droppedFields（与 CreateDataResponseSchema 同形），在 cloneData 里接上 listener，翻转两条一致性 pin 与那条 firing-control pin。⇒ @objectstack/spec 表面加宽，按 bump-level 规则取 minor。
2. 记录 clone 刻意不报告 drop，并在 schema 上写明理由。

本席位倾向 1，判据只有一条：「五个面回答、一个面沉默」这件事本身就是下一个人要重新发现的东西。若裁定 2，⛔ 请务必把理由写进 schema 的 describe/docblock，而不是只留在卡上——否则第三次发现它的人还会再开一张卡（本轮已经出现三张「解释缺失或过期导致重复发现」的卡：#15640、#15669、#15688）。

⚠️ 无论哪条：这条改的是已发布响应契约 ⇒ 按座位贴说明③，派发侧走条款②契约复审档位（needs:contract-review）。⛔ 本席位不代贴该标签、不代定档位。

⛔ 三条边界

1. ⛔ 不是 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 的委派细节。 卡片明说，且 PR 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 刻意把它留在范围外并用 protocol.readonly-insert.test.ts 的 firing-control 块钉住了这处缺席及其理由、把 changeset 措辞收窄到「会报告的那些面」。⇒ 本卡不得被读成 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 的收尾。
2. ⛔ 不要绕过 CloneDataResponseSchema 的「AS PRODUCED」性质。 该 schema 按 2026-08-25 维护者裁决是按实际产出声明的（Four client SDK routes answer a shape no published contract declares — automation.create / automation.update / search / data.clone #11924）⇒ 加成员必须与 cloneData 的真实产出同批变更，⛔ 不能先声明后实现。
3. 两条 pin 是判据不是障碍：packages/metadata-protocol/src/search-clone-schema-conformance.test.ts 逐字断言该 body 不带 droppedFields。⇒ 走路线 1 就得翻转它；⛔ 但翻转前请确认 PR 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 已落地，否则会与它的 firing-control 块打架。

Refs：PR #15395 · #14147（2026-09-03 option C 裁决）· #11924（CloneDataResponseSchema 的 AS PRODUCED 裁决）· #14147 上的契约复审 5548671173（row A12）。

_{分诊席位 · claude-opus-5 · 本轮 R+156}

---

Generated by Claude Code