metadata save door: a select field bound to a picklist no package declares saves and publishes, then is served with no options and every write to it is refused #29898

domain:devx#1 · os-warren · session_01JQwxbXGDmSYVyFomEEAdU3

Filing gate: ① product defect with a named landing point and a reproduction (reach: the public metadata doors PUT /api/v1/meta/object/NAME?mode=draft&package=PKG and POST /api/v1/packages/PKG/publish-drafts, then the data door; reproduced twice, once with a select and once with a multiselect).
Business reason: an author (or an agent writing metadata over the API) binds a field to a picklist by name and misspells it, or names a list from a package that is not installed. Both doors answer success and the draft reads _diagnostics.valid: true, so nothing tells the author. The published object then cannot store a single record with that field set, and the boot does not refuse it either. Boot and late-install loading already refuse this exact shape (describeUnresolvedPicklistReferences), so the authoring path is the one door that lets it through.
Reader who acts: domain:server, the object save door in packages/metadata-protocol (the same pre-flight #29790 added for registry refusals) and the publish promote gate; the resolver is packages/objectql/src/picklist-resolution.ts.
Dedupe (open and closed): picklist unresolved 25 hits, picklist "no options" 70, describeUnresolvedPicklistReferences 0. Nearest: #19519 (closed, the runtime resolver), #26886 (closed, a diagnostics false positive on picklist-only fields), #28659 (closed, label() on an option-less field). None covers an unresolved picklist name at the authoring doors.

QA-source: #29893 · studio-authoring.picklist-bound-select · observed beside the clauses

What happens

Measured at framework 589049b0 (main, 2026-11-03) on a stock showcase boot, as admin, in a runtime package.

1. POST /api/v1/packages {"id":"com.qa.x","name":"X","version":"0.1.0","namespace":"x","type":"app"} → 201.
2. PUT /api/v1/meta/object/x_probe?mode=draft&package=com.qa.x {"name":"x_probe","label":"Probe","sharingModel":"public_read_write","fields":{"name":{"type":"text","label":"Name"},"t":{"type":"select","label":"T","picklist":"nope_list"}}} → 200, draft _diagnostics: {valid: true}.
3. POST /api/v1/packages/com.qa.x/publish-drafts {} → 200, outcome: published.
4. GET /api/v1/meta/object/x_probe → field t is {type: select, picklist: "nope_list"} with no options.
5. POST /api/v1/data/x_probe {"name":"a","t":"bronze"} → 400 VALIDATION_FAILED: "T takes its values from picklist "nope_list", which no loaded package declares". Every value is refused.
6. A restart keeps the object published; the boot does not refuse it.

Expected: step 2 (and step 3 for a draft stored another way) refuses 422 INVALID_METADATA naming the field and the undeclared picklist, as the load doors do. The resolver's own header says such a field is "never a field served with no options".

Controls that hold: picklist: "" → 422; picklist together with options → 422; picklist on a text field → 422 ("only valid on an option type"). Studio's own picker offers only declared picklists, so this is reached through the API (or an agent), not through Studio's picker.

Mechanism (read at 589049b)

packages/objectql/src/plugin.ts calls describeUnresolvedPicklistReferences (packages/objectql/src/picklist-resolution.ts:200) when it loads packages at boot and on a late install, and refuses the load. The runtime save door in packages/metadata-protocol does not ask that question, and neither does the publish promote. #29790 added objectRegistrationRefusal to the save door for registry refusals; picklist resolution is not one of its doors.

Generated by Claude Code