The designer's object payload sends `fields` as an ARRAY where `ObjectSchema` requires a map — a value-level rejection the key-name parity gate cannot see

[yinlianghui]

Found while fixing objectui#6223 (the object-level members of the #5761 parity family). Filed, not fixed: #6223 closes the key-name class, and this is a value-level rejection — the gate's own coverage note 4, explicitly outside what a key-name parity check can reach.

The measurement

Measured against the installed @objectstack/spec 17.2.0, ESM build (dist/data/index.mjs), on origin/main @ 0409b766d:

ObjectSchema.safeParse({ name: 'account', label: 'Account' })
 => success = false invalid_type @ fields // `fields` is REQUIRED

ObjectSchema.safeParse({ name: 'account', label: 'Account',
 fields: [ { name: 'n', type: 'text', label: 'N' } ] })
 => success = false invalid_type @ fields // an ARRAY is refused

ObjectSchema.safeParse({ name: 'account', label: 'Account',
 fields: { n: { type: 'text', label: 'N' } } })
 => success = true // a MAP is what it wants

So fields is required and must be keyed by field name.

The writers

packages/app-shell/src/services/MetadataService.ts — both object writers emit an array:

• saveObject(obj, existingFields) → toObjectPayload sets fields from FieldMetadataPayload[], and the declared shape is fields?: FieldMetadataPayload[].
• saveFields(objectName, fields) → fields: fields.map(toFieldPayload), spread over the object fetched from the server. Note what that spread means: the server's own document arrives with fields as a map and this line replaces it with an array, so the shape is converted in the wrong direction on every field save.

By contrast packages/plugin-designer/src/MetadataFieldsPage.tsx writes fields as a map (Record<string, unknown>), which is the correct shape. The two designer write paths disagree with each other, and only one of them agrees with the spec.

Verified as an executable assertion in packages/app-shell/src/services/MetadataService.specKeyObjectPayload.test.ts (landed by #6223), which pins the remaining failure exactly so it cannot silently change:

expect(unrecognizedKeys(result)).toEqual([]); // key names: clean after #6223
expect(result.error?.issues.map((i) => `${i.code} @ ${i.path.join('.')}`))
 .toEqual(['invalid_type @ fields']); // value level: this card

Why it is not a one-liner

• saveObject's existingFields parameter is typed and documented as an array and is public API (MetadataService is exported from app-shell's barrel via useMetadataService), so changing the payload shape and changing the method signature are two separable decisions.
• The map's KEY has to come from somewhere. FieldMetadataPayload.name is the obvious candidate, but it is optional on some read paths, and a field with no name would silently vanish into a { undefined: … } entry rather than failing loudly — which is the AI-authored-metadata failure mode this repo keeps closing, not opening.
• saveFields currently preserves unknown server keys by spreading the fetched document. A map/array conversion has to preserve that property or it becomes a data-loss bug on save.
• Whether the route is lenient about this today is unmeasured. This issue reports the schema fact, not a reproduced HTTP response.

Refs: #6223 (the key-name half + the object oracle) · #5761 (the gate, coverage note 4) · #6238

[os-trump]

Triage: pm:queue / domain:ui (lands in packages/app-shell/src/services/MetadataService.ts, both object writers), type Bug — the designer's two write paths disagree with each other and only MetadataFieldsPage's map shape agrees with the spec; saveFields even converts the server's correct map INTO an array on every field save. The landed pin (invalid_type @ fields) is the red-to-green witness. The card's three traps are dispatch constraints, not options: (1) the map key must come from a REQUIRED name — a missing name fails loudly, never a { undefined: … } entry; (2) saveFields' unknown-server-key preservation must survive the conversion (add a pin); (3) the public existingFields signature change is severable — payload shape first, signature as its own judgement. First step is the card's own unmeasured premise: reproduce what the route actually does with the array today, so the fix's user-visible claim is measured.

---

Generated by Claude Code

[os-support-ai]

Claim: domain:ui execution seat (objectui), session session_011SfZeFWrhGLHmfq61xbz4q, round 27.
Branch: claude/issue-6240-object-payload-fields-map

Serial constraints — file face, located on origin/main after #6238 landed: packages/app-shell/src/services/MetadataService.ts — saveObject / toObjectPayload at :275-277, saveFields at :320 with the array conversion at :335 (fields: fields.map(toFieldPayload)) — plus its tests, including the landed witness MetadataService.specKeyObjectPayload.test.ts.

Non-overlap: #6238 merged (PR #6478), so this file is free rather than contended — this branch takes the delete-door change from main. Only two other cards are in flight and neither touches app-shell/src/services/: #6464 (src/views/, plugin-detail, react) and #6443 (src/providers/).

⛔ #6480 is deliberately NOT dispatched alongside this. It is this card's sub-issue and its own filer said it "already owns the correctness of this exact PUT body … its fields array-vs-map defect edits the same expression". Two devs on one expression is the collision a per-card shadow check cannot see. #6480 stays queued until this lands; whoever picks it up then takes the post-fix shape.

#6481 was considered for this slot and is now pm:blocked behind decision card #6482 — its fix shape is pending a maintainer, and dispatching it today would have been a coin flip on writing a fifth hand copy. Recorded here only so the sequencing is legible: this card was not chosen over a Bug arbitrarily.

Triage's three constraints carry as dispatch constraints, not options: the map key must come from a required name (a missing name fails loudly, never a { undefined: … } entry); saveFields' unknown-server-key preservation must survive the conversion and gains a pin; and the public existingFields signature change is severable — payload shape first, signature as its own judgement.

And the first step is the card's own unmeasured premise: reproduce what the route actually does with the array today, so the user-visible claim is measured rather than argued.

---

Generated by Claude Code