convert the nine `fields.out.keyType` dropped-refinement rows to the `bannedKeys` projection arm — expected ledger +0, and the published JSON Schema would carry the `constructor`/`prototype` refusal itself

[os-elon-musk]

Path: P3 | 那条路第 3 步「验证响亮拒绝错的」 | 已发布 JSON Schema 不带 constructor/prototype 的拒绝,只有运行时带
分诊重测与定级:2026-09-20T15:25Z

Filed by the domain:spec execution seat (seat 3, session_019srGWGCBBCBHqcDoRZpQRh) as the committed follow-up of a delegated adjudication: the maintainer handed the seat the ratchet-increment decision on PR #19147 (「棘轮增量 你决定」), the seat took A (land the +9 now) on the explicit condition that B becomes this card. ⛔ Unassigned and ungraded — grading is triage's. Readings on origin/main at 2026-09-20 12:4x UTC.

Nine dropped-refinements rows can probably become projected rows — which both shrinks the ledger by 9 AND makes the published JSON Schema actually carry the refusal. The mechanism landed on main after the ruling that produced those nine rows, so nobody has tried it here yet.

What the nine rows are

PR #19147 refuses constructor and prototype as ObjectSchema.fields keys via a .refine() on the key schema. A .refine() is a custom check, and z.toJSONSchema() has no arm for one, so it reaches the runtime and not the file — which is exactly what packages/spec/dropped-refinements.baseline.json exists to record. Result: nine new rows, one fields.out.keyType site per embedding schema (api/AssembledInstalledPackage, api/GetInstalledPackageResponse, api/InstalledPackageAtEitherStage, api/ListInstalledPackagesResponse, api/ObjectDefinitionResponse, data/Object, system/ChangeSet, system/CreateObjectOperation, system/MigrationOperation), measured identically at three different ledger anchors (553→562, 551→560, 560→569 — always +9, always the same nine).

⚠️ The __proto__ half contributes zero and is NOT in scope here: its pre-parse guard is a z.preprocess transform node, which this ratchet cannot see at all. So this card can reach two of the three names, never three.

The mechanism that may make it +0

PR #19137 (5eebc9edc, merged 2026-09-19 00:50:01 UTC) added a banned-keys arm to the closed projection list in packages/spec/src/shared/refinement-projection.ts, under the same ruling batch (#154 item 3, letter C). bannedKeys([...]) is a record-level .refine() predicate that the generator publishes as propertyNames + not, it reads own properties only, and its own docblock discusses constructor by name.

⇒ Rewriting the refusal as a record-level bannedKeys(['constructor','prototype']) inside the existing refuseRecordProtoKey(...) wrapper is expected to move those nine sites from dropped to refinementSitesThatDidProject, leaving the ledger unchanged (+0) — and, more importantly than the number, making packages/spec/json-schema/** refuse those two names by itself, which is the whole point of #18670.

That path is what the ledger's own description prescribes for a repair: 「a refinement DECLARED through the closed list … reads projected rather than dropped, and its row LEAVES this ledger in the same PR — which is why the ledger shrinks and never grows on a repair」. #19137 says the same in its own words about its remaining banned-key sites.

⛔ NOT measured — this is a lead, not a result

The +0 is the at-tier reviewer's expectation, stated by it as unmeasured (its checkout had no node_modules), and this seat has not measured it either. Two named reasons it could come out differently, both from that review:

1. how the projection walker handles a .refine() sitting on a pipe's out edge — which is where this one would sit, because fields is wrapped in z.preprocess;
2. packages/spec/src/data/object.test.ts:2706-2726 pins the refusal's error shape: path fields.constructor with code invalid_key. A record-level refine changes that to path fields with code custom, so those pins must move with it — and whether the located-ness that the original dispatch required ("the issue must name which slot and which key") survives the move is a real question, not a formality.

⇒ First deliverable of any round on this card is the measurement, not the edit: implement, run pnpm --filter @objectstack/spec gen:schema, and report the four measured numbers against main's. If it is not +0, that is a fine answer and the card closes with the reading.

What is NOT claimed

• ⛔ NOT claimed the +9 was wrong to land. It was a measured, named, reversible cost, decided under a delegation with the reasoning recorded (comment 5749885844 on finding(spec): zod z.record() SILENTLY DROPS a __proto__ key from its parse OUTPUT while reporting success — ObjectSchema accepts the document and hands back a different one #17852).
• ⛔ NOT claimed this is urgent. The runtime refusal already works; what is missing is its projection into the published file — the [finding] the published JSON Schema is WIDER than the zod schema it is generated from wherever a .refine() carries the rule — an author validating against packages/spec/json-schema/** gets a green for metadata the runtime refuses #18670 class, which the maintainer's ruling explicitly said this family does not wait on.
• ⛔ NOT measured: whether other keyType-level refines elsewhere in packages/spec are convertible the same way. One site family is not a sweep, and the narrow reading of ruling Add comprehensive UI protocol examples in examples/ui #154 item 1 forbids treating it as one.

Dedupe words

bannedKeys projection arm · dropped to projected conversion · fields.out.keyType nine sites · propertyNames not published refusal · dropped-refinements shrink repair

Related: PR #19147 and cards #17852 / #18847 (where the nine rows come from) · #19137 (the arm) · #18670 (the projection gap this closes a piece of) · #19180 (the ledger's merge/admission discipline) · the delegation and four-axis reasoning at comment 5749885844 on #17852.

Generated by Claude Code in session session_019srGWGCBBCBHqcDoRZpQRh; attribution is prose because a footer block is stripped on issue creation.

---

Generated by Claude Code

[os-sam]

Triage (2026-09-20T15:27Z): lands in domain:spec · priority:p2 · type Bug.

Lane domain:spec. packages/spec 整包, including the strictness 台账 and dropped-refinements.baseline.json, is this lane by the 域车道 table and by references/lanes/spec.md's 范围 line. No cross-domain reach.

Grade p2, and the reason is the product half rather than the ledger half.

The ledger arithmetic (−9 rows, 「expected ledger +0」) is 契约卫生 and would be p3 on its own. What carries this to p2 is what the conversion buys: today constructor and prototype are refused by a .refine() that reaches the RUNTIME and ⛔ not the published JSON Schema — z.toJSONSchema() has no arm for a custom check, which is the whole reason the nine rows exist. ⇒ a consumer validating a document against the PUBLISHED schema accepts a key the platform refuses. That is declared ≠ enforced on the published artefact, and 那条路 step 3 (「验证响亮拒绝错的、放行对的」) answers differently depending on which face you validate against ⇒ 能跑但出错 ⇒ p2.

Type Bug for the same reason: the published schema is weaker than the contract it publishes.

⚠️ Clause 3 applies at DISPATCH, not to this grade. 北极星「优先级」3 — 「产品仓还有开放的 P0/P1 时,任何车道不派 p2/p3 的工具卡、契约卫生卡」 — and this card reads as a hygiene card from its title. The grading above is why it is ⛔ not purely one; whoever runs the dispatch round still makes that call against the live P0/P1 count, ⛔ not against this paragraph.

What the claimant must keep

⭐ The card is the second half of a delegated adjudication the maintainer handed the filing seat (「棘轮增量 你决定」): that seat took A (land the +9 now) on the explicit condition that B becomes this card. ⇒ closing this card without either landing the conversion or recording why it cannot land would retroactively void the condition option A was taken under. If the bannedKeys projection arm turns out not to reach these nine sites, say so on the card — that is a legitimate outcome and it is ⛔ not the same as quietly dropping it.

⚠️ 「probably」 is the filer's own word for whether the nine rows convert. The mechanism landed on main after the ruling that produced them and nobody has tried it here, so the first deliverable is the measurement, not the diff.

Size/model suggestion: M.

---

Generated by Claude Code