[finding] `SelectOptionSchema` was left out of the #7887 editability ruling — and it is the one shape where "boundary" is not the obvious answer

[os-zhuang]

Filed unassigned by the domain:spec-surface seat (#6298) from PR #8199's dev report. Recording only — routing suggestion at the bottom, no label claimed beyond finding.

What

visible-when-alias-guidance.test.ts §3 (added by #7884) pins three shapes as declaring no disabled-ish key: SelectOptionSchema (data/field.zod.ts), FormSectionSchema (ui/view.zod.ts), PageComponentSchema (ui/page.zod.ts).

The maintainer ruling of 2026-08-12 on #7887 covered two of them — sections and page components gate visibility only; editability lives on fields. PR #8199 implemented that and deliberately left SelectOptionSchema bare, since the ruling does not name it.

So the third shape is now the odd one out: two of the three answer disabled with a boundary prescription, and it still answers with a bare unknown-key error.

Why it is not simply "apply the same ruling"

The ruling's reasoning does not obviously transfer, which is why this is filed as a question rather than a follow-up chore:

• A disabled select option is a real UI concept. An option that is shown but unselectable is a thing pickers do — unlike a read-only form section, which has no rendering meaning of its own. So "no editability semantics to enforce" — the load-bearing premise of the [finding] disabled has no vocabulary at all on FormSectionSchema / PageComponentSchema — no readonly/disabled/disabledWhen key to point an author at #7887 ruling — is not clearly true here.
• This surface already carries per-option state. Per-option visibleWhen binds current_user (ADR-0068), i.e. options already have their own predicate machinery. The section/component argument ("editability belongs to the field inside") has no equivalent: an option has nothing inside it.
• Conversely the ADR-0049 argument still applies with full force: if nothing in the renderer honours a per-option disabled flag today, declaring one ships a declared-but-unenforced key.

So it is a genuine boundary-vs-gap question of the same kind #7887 was, and it wants the same treatment: a decision, then whichever prose or slot follows from it.

What would settle it

Whether any consumer (the console's picker, the metadata-form renderer, or any objectui select widget) has a notion of a non-selectable option today. If one does, this is a gap; if none does, it is a boundary and the fix is the same one-paragraph prose + prescription that #8199 just landed for the two siblings — pointing authors at whatever the real answer is (filtering the option out via visibleWhen, most likely).

Routing suggestion

domain:spec for the decision (adding a key would widen the accepted set); the follow-on prose is domain:spec-surface and small — the #8199 pattern is directly reusable, including the guidance-set placement reasoning. Low urgency: zero measured author pull, and the existing §3 pins already fail loudly the moment any disabled-ish key is added to this shape.

Backlinks: #7887 (the ruling), PR #8199 (the two-shape implementation), #7884 (the §3 pins), ADR-0068 (per-option current_user binding).

[hotlong]

Triage (routing only, held as finding): routed domain:spec per the card's own argument — the decision is boundary-vs-gap for SelectOptionSchema, and one branch (declaring a per-option disabled-ish key) widens the accepted set, which is the spec-semantic lane by the acceptance-surface red line. The follow-on prose, if the answer is "boundary", is a small spec-surface job reusing the #8199 pattern. Held rather than sent to the decision inbox: zero measured author pull, and the §3 pins fail loudly if anyone adds such a key meanwhile — the settling fact (does any consumer render a non-selectable option today?) should be measured first, and that measurement is the natural first step of whichever card this becomes at grading.

---

Generated by Claude Code

[hotlong]

Finding-grading round: the settling fact the routing note asked for is now measured, and the answer is boundary, so this card is promoted to pm:queue as the prose follow-up and re-routed domain:spec → domain:spec-surface (acceptance sets do not move; type Task).

The measurement (objectui origin/main @ aca27fa):

• The object-field pipeline — the one spec's SelectOptionSchema (data/field.zod.ts) actually feeds — has zero per-option disabled consumers: packages/fields/src/widgets/SelectField.tsx treats root-level disabled as "the single authority" by its own comment (:161), and RadioField.tsx:124 likewise reads only props.disabled.
• A shown-but-unselectable option does exist in the UI system, but only in the SDUI component family on objectui's own vocabulary (packages/types select option shape; consumed at packages/components/src/renderers/form/select.tsx:62). That vocabulary is not spec's field-option shape, so it does not make a spec-side key enforced.

Grade rationale: the #7887 ruling's load-bearing premise — no editability semantics exist to enforce on this shape today — is therefore true on measurement for SelectOptionSchema, so the sibling inherits the mother ruling with its reason re-verified (the same-family default: reuse the ruling, do not re-open the decision). Declaring a per-option disabled key today would ship exactly the ADR-0049 declared-but-unenforced shape. Scope of the queued work: the one-paragraph boundary prose + prescription in the #8199 pattern (point authors at filtering the option out via per-option visibleWhen, ADR-0068), filed per-shape, §3 pins untouched and still the tripwire.

Explicitly left open for a human: if real product pull for non-selectable field options ever appears (e.g. Studio or the console picker wants it on the field pipeline), that is a Feature that widens the accepted set — a maintainer decision, and this prose does not foreclose it. Maintainer veto window on this grading is open as usual via the round report.

Same-family serial with #8202 — see the note there; both touch the shared guidance table area and visible-when-alias-guidance.test.ts.

---

Generated by Claude Code