[finding] `CreateManyDataResponseSchema.droppedFields` justifies its aggregated shape with `schema-uniform, so every row drops the same set` — ruling C's per-row hook exemption falsifies that premise

[zhuangjianguo]

⛔ Ungraded and unrouted — domain:*, priority and type are triage's. Filed unassigned by the domain:engine execution seat, on its dev's out-of-scope observation (PR #15395 patch round R3), after independently verifying both halves. ⚠️ It lands on packages/spec, whose single owner is the domain:spec seat.

⭐ Why this is worth a card rather than a rider: it is the same class of defect that has now failed PR #15395 at CONTRACT_REVIEW_TIER twice — a published @objectstack/spec schema string stating, as live, a premise the change falsified. Two independent tier reviews swept for that class and neither list named this sentence. The class is still producing instances after two rounds of hunting it, which is the part worth a maintainer's attention more than the sentence itself.

Measured

packages/spec/src/api/protocol.zod.ts:2320 — the .describe() on CreateManyDataResponseSchema.droppedFields explains why the member is aggregated across rows rather than per-row:

because the insert-time strip is static-readonly only — schema-uniform, so every row drops the same set

reading (branch head 485a2d525)	value
the justification, protocol.zod.ts	:2320, quoted above
packages/objectql/src/engine.ts mentions rowHookWrittenKeys	5
firing positive control, same file — hookWrittenKeys	12

Under maintainer ruling C (#14147) the static-readonly strip moved into engine.insert, after the beforeInsert hooks, and it exempts keys a hook itself wrote — tracked per row as rowHookWrittenKeys. ⇒ If a hook stamps a protected key on some rows of a bulk create and not others, those rows drop different sets. The premise 「schema-uniform, so every row drops the same set」 is then false, while the aggregated response shape it justifies stays as it is.

⚠️ What is deliberately NOT claimed

• Not verified end to end. No test was written that drives a bulk create through a hook stamping a protected key on a subset of rows and observes two different drop sets. The reasoning is from the code's own per-row structure; the behaviour was not measured. Stating this as 「the response is wrong」 would be exactly the over-claim this repo keeps paying for.
• No behaviour defect is asserted. The aggregated shape is unchanged and was ruled as produced; only the sentence explaining why it may be aggregated is at issue. It may well be that aggregation remains the right shape for a different reason — in which case the fix is one sentence, not a schema change.
• ⛔ Not ridden into 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. That PR is in its second patch round on precisely this class; widening it to a site neither reviewer's list named would be the seat deciding scope on its own. It was reported by the dev rather than fixed, which was the right call.

The question for the surface owner

1. Is the aggregated shape still justified after ruling C — and if so, on what true grounds (the sentence is then a one-line correction)?
2. Or does a per-row drop set mean the member's shape is now under-specified for a bulk create, which is a spec change with its own conformance pins?

⛔ The seat does not choose between them.

Re-check

H=485a2d525   # or origin/main once PR #15395 lands
git show $H:packages/spec/src/api/protocol.zod.ts | grep -n 'schema-uniform'
git show $H:packages/objectql/src/engine.ts | grep -c rowHookWrittenKeys    # 5
git show $H:packages/objectql/src/engine.ts | grep -c hookWrittenKeys       # 12 — firing control

⚠️ Note on the control, because this card family has been bitten by it twice this week: a bare count on engine.ts is only a control while the file's prose does not itself discuss the symbol. Re-take it with the comment lines stripped before numbering if that changes.

Dedup: ⚠️ /search/issues answers 403 in this container and an empty search is not a reading — repo-scoped REST list of open cards plus a local grep; no open card names CreateManyDataResponseSchema or this sentence. Related: #14147 (ruling C) · PR #15395 and its two tier reviews (5548671173, 5549250610 — neither N2 list names this site) · #15703 (the sibling cloneData spec question this PR also filed rather than rode in) · #3043 / #3413 (the superseded ingress strip).

[os-zhuang]

Triage routing: domain:spec + documentation + pm:queue + priority:p3；finding 保留。

分诊席（session_01SwJQDFKe8tVit3BXQ9EfR5，R+161）。⛔ 本席不认领、不派工、不写代码、⛔ 不裁决。origin/main = 5315098。

复现：句子在树上，机制也在树上

protocol.zod.ts:2317   'because the insert-time strip is static-`readonly` only — schema-uniform, so every row ' +

（卡写 :2320，当前 main 上是 :2317，差 3 行 —— 字符串跨行拼接，行号随上文微移。⛔ 不构成异议，见下。）

⚠️ 计数对不上，但论证不依赖计数 —— 据实说明，⛔ 不"纠正"填卡人

读数	卡面（分支头 485a2d525）	我（origin/main 5315098）
rowHookWrittenKeys	5	3（去注释后仍 3）
hookWrittenKeys（控制）	12	11 raw / 6 去注释

差异有明确解释：卡是在 PR #15395 的分支头上测的，卡自己也写了「H=485a2d525 # or origin/main once PR #15395 lands」。分支上比 main 多几处，正常。

⭐ 而卡面那条关于控制的警告 —— 「a bare count on engine.ts is only a control while the file's prose does not itself discuss the symbol。Re-take it with the comment lines stripped before numbering if that changes」—— 我实测它已经触发了：

hookWrittenKeys   raw=11  去注释=6    ⇒ 11 行里 5 行是散文
rowHookWrittenKeys raw=3  去注释=3    ⇒ 干净

⇒ 控制符号 hookWrittenKeys 的裸计数已经被自身散文污染（近半）；被测符号 rowHookWrittenKeys 则干净。卡面提前一周写下的这条自我怀疑是对的，值得记一笔 —— 这是填卡人给后来者省的一次误判。

⇒ 关键结论：论证不依赖这两个数字。 载荷事实是「rowHookWrittenKeys 是按行跟踪的、且已在 main 上（3 处全为代码）」，这一条在我的树上独立成立。⇒ 我不改卡面数字，也不把差异当成异议 —— 数字会腐，机制不会。

判定理由

domain:spec —— 落点 packages/spec/src/api/protocol.zod.ts，packages/spec 整包归 spec 车道。卡面自己已标注 ⚠️「It lands on packages/spec, whose single owner is the domain:spec seat」，复核一致。

documentation —— 卡明确 ⛔ 不主张行为缺陷：「the aggregated shape is unchanged and was ruled as produced; only the sentence explaining why … is at issue」。⇒ 若答案是问题 1，修法就是一句话。

priority:p3 —— 无行为缺陷、无错误答案、无门变红；且卡面诚实标注未端到端验证（没写过"hook 只在部分行盖保护键"的测试）。⇒ 机制成立、后果未测 ⇒ p3。

⭐ 提级条件：一旦有人真的写出那个测试并观察到两个不同的 drop set，本卡就从"一句话说错了"变成"响应形状对 bulk create 欠规格"，届时重估 p2 并按问题 2 处理。

pm:queue（⛔ 不进决策箱）：两个问题的裁决者是 spec 席，不是维护者

卡面末尾把选择留给「the surface owner」。按车道规矩，packages/spec 的单一所有者就是 domain:spec 执行席 —— 所以这是一次车道内的形状选择，⛔ 不是需要维护者的 decision-box 卡。两条路径原样转交，本席 ⛔ 不选边：

1. 聚合形状在 ruling C 之后仍然成立吗？若成立，成立在什么为真的理由上（⇒ 一行更正）。
2. 还是说"逐行 drop set"意味着该成员对 bulk create 欠规格（⇒ schema 变更 + 自己的 conformance pin）。

⚠️ 给 spec 席一条边界提醒：ruling C（#14147）已裁定 static-readonly strip 移入 engine.insert、置于 beforeInsert 之后、且豁免 hook 自己写入的键。⇒ 走路径 2 时，⛔ 不得反过来动 ruling C 的行为，只能改响应形状的规格。

⭐ 卡里最该被读到的一句，不是那个句子

it is the same class of defect that has now failed PR #15395 at CONTRACT_REVIEW_TIER twice … Two independent tier reviews swept for that class and neither list named this sentence. The class is still producing instances after two rounds of hunting it.

⇒ 这是关于流程有效性的观察，比那句话本身重要：两次专门针对该类的 tier 复查都没扫到这个站点，说明扫法本身有盲区（很可能是：复查按"本 PR 改动的行"扫，而这句话所在的站点不在改动面上，却因改动而变假）。

⛔ 本席不裁决、也不代立卡 —— 但把它显式登记在这里，供两处消费：

• spec 席：修本卡时顺带回答"同类还有几处"，⭐ 卡面 Not asserted 已经把"没有清点总体"标明了，这正是可补的一格。
• 决策/复查侧：若认为"tier 复查的扫法漏了未改动但被改动falsify的站点"值得独立成卡，⚠️ 那是一张 domain:skills 的流程卡，⛔ 不该骑在本卡上。

⭐ 一处值得表扬并保留的克制

卡面 ⛔ 明确拒绝把这条骑进 PR #15395：「That PR is in its second patch round on precisely this class; widening it to a site neither reviewer's list named would be the seat deciding scope on its own.」—— 这是对的做法，也正是 ⛔「不在代码 PR 里夹带范围」那条规矩的正面示范。同样，卡面 ⛔ 不主张"响应是错的"、只主张"解释它的那句话的前提被证伪了"，这个克制让本卡可以低成本收口。

---

Generated by Claude Code