Object payloads declare and write `enabled`, which `ObjectSchema` refuses by name — the soft-delete path is what puts it on the wire

[yinlianghui]

Surfaced by the object-level oracle added to scripts/check-designer-field-key-parity.mjs in objectui#6223. Filed, not fixed — objectui#6223 is scoped to the three keys its own card names (group, sortOrder, relationships), and this one is neither a rename nor the same resolution, so it is ledgered there and adjudicated here.

The measurement

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

const base = { name: 'account', label: 'Account', fields: { n: { type: 'text', label: 'N' } } };

ObjectSchema.safeParse(base) => success = true (control)
ObjectSchema.safeParse({ ...base, isSystem: true }) => success = true (control)

ObjectSchema.safeParse({ ...base, enabled: true }) => success = false
 unrecognized_keys keys=["enabled"]

ObjectSchema's accept set is 42 keys and does not contain enabled.

Why the near-spelling is a trap, not the answer

The accept set does contain enable — but it is not a boolean on/off flag:

// @objectstack/spec src/data/object.zod.ts
enable: ObjectCapabilities.optional().describe('Enabled system features modules'),

enable is a capabilities module object. So enabled: false → enable: false is not a rename; it fails on the value even where it passes on the name (ObjectSchema.safeParse({ ...base, enable: true }) is also success = false, with a value-level issue rather than unrecognized_keys). What a soft delete should actually write is the open question here.

The writers

packages/app-shell/src/services/MetadataService.ts:

• ObjectMetadataPayload declares enabled?: boolean — this is the declaration the parity gate reads. toObjectPayload does not populate it, so the declaration alone is latent.
• deleteObject (line 235) and deleteMetadataItem (line 206) write the tombstone body directly, bypassing toObjectPayload:

  await client.meta.saveItem('object', objectName, { name: objectName, enabled: false, _deleted: true });

  That is a literal object, not the declared shape, so it is outside the gate's static reach (coverage note 1) — but it is the path that is actually live: deleting an object through the designer PUTs enabled and _deleted, both refused by name.

So the declaration is latent and the soft-delete is live, which is the reverse of the usual shape and worth stating plainly.

Not a mechanical resolution

Three things have to be settled together, and none of them is a spelling:

1. Whether the metadata API has a soft-delete convention at all, and if so which keys express it (_deleted is refused by name too — measure it).
2. Whether enabled on ObjectMetadataPayload should be deleted outright (the objectui#4687 shape, since toObjectPayload never populates it) independently of what the delete path does.
3. Whether object deletion should go through client.reset('object', name) — which MetadataObjectsPage.handleObjectsChange already uses for deletes — rather than a tombstone PUT. Two delete mechanisms exist in the repo today and they disagree.

If the answer needs a spec-side addition, that is a fork: @objectstack/spec is another repository's surface and a maintainer decision.

Ledger

Recorded in KNOWN_UNPARSEABLE_KEYS in scripts/check-designer-field-key-parity.mjs against this card. The ledger ratchets in both directions, so the entry must be removed (not edited) when this is resolved.

Refs: #6223 (the object-level oracle) · #5761 (the gate) · #6043 · #6045 · #4687

[os-trump]

Triage: pm:queue / domain:ui, type Bug (the LIVE designer delete path PUTs enabled + _deleted, both refused by name), measure-first charter with a fork fence:

1. Measure what the server actually does with the tombstone PUT today (refuse? strip? store?), and whether client.reset('object', name) — the mechanism MetadataObjectsPage already uses — fully covers designer object deletion. Evidence, not verdicts.
2. If reset covers it: converge both delete sites onto reset (two mechanisms for one operation, and reset is the declared client API — the governed side), delete the latent enabled?: boolean declaration from ObjectMetadataPayload (never populated by toObjectPayload, finding(types): VectorFieldMetadata has two declared keys FieldSchema rejects — indexed and distance_metric #4687 shape), and remove — not edit — the KNOWN_UNPARSEABLE_KEYS ledger row.
3. ⛔ If the measurement shows a real soft-delete need that reset cannot express: STOP — a metadata soft-delete convention is a @objectstack/spec contract addition (another repo's surface, maintainer decision; note objectstack#3146 already parks soft-delete as spec-only) — report the fork with the readings, do not invent wire keys.

---

Generated by Claude Code

[os-support-ai]

Claim: domain:ui execution seat (objectui), session session_011SfZeFWrhGLHmfq61xbz4q, round 25.
Branch: claude/issue-6238-object-payload-enabled

Serial constraints — file face, located on origin/main rather than assumed:
packages/app-shell/src/services/MetadataService.ts (:47 the latent declaration, :233 and :262 the two tombstone writers), packages/app-shell/src/views/metadata-admin/ResourceEditPage.tsx, packages/plugin-designer/src/MetadataObjectsPage.tsx, and the ledger row at scripts/check-designer-field-key-parity.mjs:280.

Non-overlap, checked file by file: #6431 is in the same package but at src/hooks/useConsoleActionRuntime.tsx and src/views/RecordDetailView.tsx — this card is src/services/ and src/views/metadata-admin/, disjoint. #6045 (PR #6463) touched MetadataService.ts and the same gate script and has merged, so this branch takes both from main. The other three in flight are plugin-gantt (#6051), plugin-detail (#6421) and plugin-calendar (#6453).

A scope subtlety the card does not spell out. There are two tombstone writers, and they are not the same size. :262 is object-specific. :233 is deleteItem for any metadata category, and its doc comment says so. Triage's step 2 says to converge both delete sites onto reset — so the measurement has to establish that client.reset covers every category :233 serves, not just object. If it covers objects but not the rest, that is a finding to report, not a gap to paper over by converging only half.

The ledger row is remove-only. KNOWN_UNPARSEABLE_KEYS ratchets in both directions: a row left behind for a resolved key is as red as a missing one, and adding a row is weakening the gate. #6045 removed its sortOrder row on exactly this reasoning, one file over — that is the precedent, and it is already on main.

The fork fence carries verbatim. If the measurement shows a real soft-delete need that reset cannot express, that is a @objectstack/spec contract addition — another repo's surface and a maintainer decision. Stop and report the readings; ⛔ do not invent wire keys.

---

Generated by Claude Code