@@ -0,0 +1,19 @@
+---
+'@objectstack/spec': patch
+---
+
+fix(spec): `ObjectSchema.fields` refuses `constructor` and `prototype` at the offending key (`fields.constructor`, `fields.prototype`), not at the `fields` slot
+
+Clause-②: no
+
+A field map carrying a key named `constructor` or `prototype` is refused, as before. The
+refusal used to be reported at the path `fields`, which names no field, so a form reading the
+structured issues of a refused save could not point at the field that caused it. It is now
+reported at that key, like the `__proto__` refusal (`fields.__proto__`) and the key grammar's
+`invalid_key` refusal (`fields.Bad Name`) already are. A document carrying both names gets two
+issues, one at each key, where it used to get one at the slot.
+
+Nothing else moves. The same keys are refused and the same documents are accepted. The issue
+code (`custom`) and the message are unchanged. The published JSON Schema states the same ban:
+it is now written as one `propertyNames` clause per name inside `allOf` instead of one clause
+naming both, which accepts and refuses exactly the same documents.
@@ -2774,20 +2774,46 @@ describe('ObjectSchema.fields — __proto__ / constructor / prototype key refusa
       });
       expect(result.success).toBe(false);
       if (result.success) return;
-      // ⚠️ The refusal is located at the SLOT and no longer at the offending
-      // key. The `banned-keys` arm is a RECORD-level predicate — the only shape
-      // the closed projection list can publish — and `.refine()` carries no
-      // per-key path, so before #19346 this read `fields.<the key>` with code
-      // `invalid_key` and the reason nested one level under zod's fixed
-      // "Invalid key in record". The ban list is closed and two names long, so
-      // the slot is still named and the message names both keys in full.
-      const issue = result.error.issues.find((i) => i.path.join('.') === 'fields');
+      // [#20997] Located AT the offending key — `fields.<the key>` — the path
+      // the `__proto__` guard and the key grammar already report at, so
+      // `saveMetaItem`'s structured issues can point a Studio form at the
+      // field. The `banned-keys` arm is still a RECORD-level predicate (the
+      // only shape the closed projection list can publish); what puts the path
+      // on the key is one single-name refine per reserved name, each carrying
+      // its own name as a static `path`.
+      const issue = result.error.issues.find((i) => i.path.join('.') === `fields.${reserved}`);
       expect(issue).toBeDefined();
       expect(issue?.code).toBe('custom');
       expect(issue?.message).toMatch(/constructor.*prototype|prototype.*constructor/s);
+      // Exactly one refusal, and none left at the bare slot — a pin that only
+      // looked for the keyed issue would pass beside a slot-level duplicate.
+      expect(result.error.issues.map((i) => i.path.join('.'))).toEqual([`fields.${reserved}`]);
     },
   );
 
+  it('refuses `constructor` and `prototype` together as TWO issues, each at its own key', () => {
+    const result = ObjectSchema.safeParse(
+      JSON.parse(
+        '{"name":"lead","label":"Lead","fields":{"constructor":{"type":"text","label":"C"},"prototype":{"type":"text","label":"P"}}}',
+      ),
+    );
+    expect(result.success).toBe(false);
+    if (result.success) return;
+    expect(result.error.issues.map((i) => [i.code, i.path.join('.')])).toEqual([
+      ['custom', 'fields.constructor'],
+      ['custom', 'fields.prototype'],
+    ]);
+  });
+
+  it('CONTROL: a key the snake_case grammar refuses keeps its own path and code (`invalid_key` at the key)', () => {
+    const result = ObjectSchema.safeParse(
+      JSON.parse('{"name":"lead","label":"Lead","fields":{"title":{"type":"text","label":"T"},"Bad Name":{"type":"text","label":"B"}}}'),
+    );
+    expect(result.success).toBe(false);
+    if (result.success) return;
+    expect(result.error.issues.map((i) => [i.code, i.path.join('.')])).toEqual([['invalid_key', 'fields.Bad Name']]);
+  });
+
   it('still accepts an ordinary document with no reserved field names', () => {
     const result = ObjectSchema.safeParse({
       name: 'lead',
@@ -2865,7 +2891,13 @@ describe('ObjectSchema.fields — __proto__ / constructor / prototype key refusa
     // The record's own key-TYPE rule survives — the ban is CONJOINED, never
     // substituted, so the reference tables keep the shape they always printed.
     expect(node.propertyNames).toEqual({ type: 'string', pattern: '^[a-z_][a-z0-9_]*$' });
-    expect(node.allOf).toEqual([{ propertyNames: { not: { enum: ['constructor', 'prototype'] } } }]);
+    // One clause per reserved name (#20997): each name is its own single-name
+    // refine so its refusal can carry the name as its path, and the generator
+    // conjoins the two bans — the same rule as one two-name `enum`.
+    expect(node.allOf).toEqual([
+      { propertyNames: { not: { enum: ['constructor'] } } },
+      { propertyNames: { not: { enum: ['prototype'] } } },
+    ]);
   });
 
   it('the runtime and the published keywords agree on every document in the corpus', () => {
@@ -2876,6 +2908,7 @@ describe('ObjectSchema.fields — __proto__ / constructor / prototype key refusa
       JSON.parse('{"constructor":{"type":"text","label":"R"}}'),
       JSON.parse('{"prototype":{"type":"text","label":"R"}}'),
       JSON.parse('{"title":{"type":"text","label":"T"},"constructor":{"type":"text","label":"R"}}'),
+      JSON.parse('{"constructor":{"type":"text","label":"R"},"prototype":{"type":"text","label":"R"}}'),
       // LIT CONTROLS — names the ban does NOT cover. A rule that banned by
       // prefix, or that asked `in` instead of own-property equality, fails
       // here: `to_string` is not `toString`, and `constructors` is not
@@ -2897,6 +2930,6 @@ describe('ObjectSchema.fields — __proto__ / constructor / prototype key refusa
     const census = collectDroppedRefinements('data/Object', ObjectSchema);
     expect(census.dropped.map((site) => site.path)).not.toContain('fields.out.keyType');
     const site = census.projected.find((s) => s.path === 'fields.out');
-    expect(site?.declaredPatterns).toEqual(['banned-keys']);
+    expect(site?.declaredPatterns).toEqual(['banned-keys', 'banned-keys']);
   });
 });
@@ -1954,45 +1954,58 @@ const ObjectSchemaBase = strictObject(
    * Data Model
    */
   fields: refuseRecordProtoKey(
-    z.record(
-      z.string()
-        .regex(/^[a-z_][a-z0-9_]*$/, {
-          message: 'Field names must be lowercase snake_case (e.g., "first_name", "company", "annual_revenue")',
+    // [#17852, #19346] The three JS-prototype names are refused by
+    // TWO mechanisms, because zod reaches them at two different depths:
+    //
+    //   - `__proto__` reaches NO schema at all — zod's record parser skips it
+    //     with an unconditional `continue` ABOVE the key schema — so it is
+    //     refused on the RAW input by `refuseRecordProtoKey` around this.
+    //   - `constructor` and `prototype` DO reach the parse (ordinary
+    //     lowercase words the snake_case regex below already admits) and are
+    //     refused HERE, on the RECORD, through the closed projection list's
+    //     `banned-keys` arm.
+    //
+    // ⭐ The arm — and not the key-schema `.refine()` it replaces (#19147) —
+    // is what carries the refusal into `packages/spec/json-schema/**`.
+    // `z.toJSONSchema()` has no arm for a `custom` check, so a rule written
+    // on the KEY schema was enforced by the runtime and ABSENT from the
+    // published file: nine `fields.out.keyType` rows in
+    // `dropped-refinements.baseline.json`, one per embedding schema, and a
+    // validator reading the published contract answered PASS on a document
+    // the platform refuses by name. Declared through `bannedKeys`, the same
+    // rule is published as `propertyNames` + `not` and those nine rows leave
+    // the ledger (#19346, closing a piece of #18670). The accept set is
+    // unchanged in both directions — `bannedKeys` reads OWN properties, which
+    // is exactly what the key schema judged.
+    //
+    // ⭐ [#20997] ONE refine PER NAME, each located AT its key
+    // (`fields.constructor`, `fields.prototype`) — the path the `__proto__`
+    // guard and the key grammar's `invalid_key` already report at, and the one
+    // `saveMetaItem`'s structured issues need for a Studio form to highlight
+    // the offending field. `.refine()`'s `path` is STATIC, so a single
+    // two-name predicate could only ever name the slot; one single-name
+    // predicate per name makes the path a constant again, and the name is ONE
+    // string read twice — into the ban and into the path — so the two cannot
+    // drift. ⛔ Not a `.superRefine()` with a computed path: that check holds
+    // no readable predicate, so the generator could not project it and the
+    // published file would go wide again (the nine rows above would return).
+    // The published keywords are the same rule, conjoined one clause per name
+    // (`not enum [a, b]` ≡ `not enum [a]` ∧ `not enum [b]`), and the message
+    // and `custom` code are byte-identical to the one-refine spelling.
+    (['constructor', 'prototype'] as const).reduce(
+      (record, reserved) =>
+        record.refine(bannedKeys([reserved]), {
+          message: 'Field names must not be "constructor" or "prototype" (reserved JavaScript prototype property names).',
+          path: [reserved],
         }),
-      FieldSchema,
-    )
-      // [#17852, #19346] The three JS-prototype names are refused by
-      // TWO mechanisms, because zod reaches them at two different depths:
-      //
-      //   - `__proto__` reaches NO schema at all — zod's record parser skips it
-      //     with an unconditional `continue` ABOVE the key schema — so it is
-      //     refused on the RAW input by `refuseRecordProtoKey` below.
-      //   - `constructor` and `prototype` DO reach the parse (ordinary
-      //     lowercase words the snake_case regex above already admits) and are
-      //     refused HERE, on the RECORD, through the closed projection list's
-      //     `banned-keys` arm.
-      //
-      // ⭐ The arm — and not the key-schema `.refine()` it replaces (#19147) —
-      // is what carries the refusal into `packages/spec/json-schema/**`.
-      // `z.toJSONSchema()` has no arm for a `custom` check, so a rule written
-      // on the KEY schema was enforced by the runtime and ABSENT from the
-      // published file: nine `fields.out.keyType` rows in
-      // `dropped-refinements.baseline.json`, one per embedding schema, and a
-      // validator reading the published contract answered PASS on a document
-      // the platform refuses by name. Declared through `bannedKeys`, the same
-      // rule is published as `propertyNames` + `not` and those nine rows leave
-      // the ledger (#19346, closing a piece of #18670). The accept set is
-      // unchanged in both directions — `bannedKeys` reads OWN properties, which
-      // is exactly what the key schema judged.
-      //
-      // ⚠️ The refusal is located at the SLOT (`fields`, code `custom`) rather
-      // than at the offending key (`fields.constructor`, code `invalid_key`):
-      // a record-level predicate is the only shape the closed list can project,
-      // and `.refine()` carries no per-key path. The ban list is closed and two
-      // names long, so the message names both in full.
-      .refine(bannedKeys(['constructor', 'prototype']), {
-        message: 'Field names must not be "constructor" or "prototype" (reserved JavaScript prototype property names).',
-      }),
+      z.record(
+        z.string()
+          .regex(/^[a-z_][a-z0-9_]*$/, {
+            message: 'Field names must be lowercase snake_case (e.g., "first_name", "company", "annual_revenue")',
+          }),
+        FieldSchema,
+      ),
+    ),
     'fields',
   ).describe('Field definitions map. Keys must be snake_case identifiers; "__proto__", "constructor" and "prototype" are refused.'),
   indexes: z.array(IndexSchema).optional().describe('Database performance indexes'),
 
@@ -54,14 +54,19 @@ import { z } from 'zod';
  * refuse a name for slots whose accept set no ruling has narrowed.
  *
  * `ObjectSchema.fields` (`data/object.zod.ts`) is the slot that does, and since
- * #19346 it refuses them with a RECORD-level `bannedKeys(['constructor',
- * 'prototype'])` rather than in its key grammar. The reason is the PUBLISHED
- * file and not the runtime: a `.refine()` on the key schema is a `custom`
- * check, which `z.toJSONSchema()` has no arm for, so such a rule reaches the
- * runtime and never `packages/spec/json-schema/**` — it held nine
- * `fields.out.keyType` rows in `dropped-refinements.baseline.json` saying
- * exactly that. Declared through the closed projection list's `banned-keys`
- * arm, the same rule is published as `propertyNames` plus `not`.
+ * #19346 it refuses them with RECORD-level `bannedKeys` refines rather than in
+ * its key grammar. The reason is the PUBLISHED file and not the runtime: a
+ * `.refine()` on the key schema is a `custom` check, which `z.toJSONSchema()`
+ * has no arm for, so such a rule reaches the runtime and never
+ * `packages/spec/json-schema/**` — it held nine `fields.out.keyType` rows in
+ * `dropped-refinements.baseline.json` saying exactly that. Declared through
+ * the closed projection list's `banned-keys` arm, the same rule is published
+ * as `propertyNames` plus `not`.
+ *
+ * Since #20997 that is ONE single-name refine per name, whose static `path`
+ * is that name, so each refusal is located at `fields.<name>` exactly as this
+ * guard's own refusal is located at `fields.__proto__` — a record-level
+ * predicate keeps the projection, and a per-name one keeps the path.
  *
  * ⛔ That route is not open to `__proto__`, here or anywhere: this wrapper's
  * guard is a pre-parse `z.preprocess` node, which the projection cannot see