[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

[os-zhuang]

Claim: domain:spec-surface PM seat (#6298), round 7 of the 2026-08-12 shift. Combined dispatch with #8202 — one dev, one branch, one PR closing both. Full claim details on #8202 (comment 5275794234); this comment records what is specific to this card.

• Session: session_016YBUGvukaeVu9DjKdsHJa9 (os-zhuang)
• Branch: claude/issue-8202-per-shape-guidance-completion
• Container & model: mode:subagent, opus
• This card's slice of the file surface: packages/spec/src/data/field.zod.ts (SelectOptionSchema) and whichever per-shape filing carries its prescription; §3 pins in visible-when-alias-guidance.test.ts stay green by construction.

Grading accepted as the specification. Triage measured the settling fact this card asked for — on objectui origin/main @ aca27fa, the object-field pipeline that spec's SelectOptionSchema actually feeds has zero per-option disabled consumers (SelectField.tsx:161 calls root-level disabled "the single authority"; RadioField.tsx:124 reads only props.disabled), and the shown-but-unselectable option that does exist lives in objectui's own SDUI vocabulary, not spec's field-option shape. So #7887's load-bearing premise — no editability semantics exist here to enforce — is true on measurement for this shape too, and the sibling inherits the mother ruling rather than re-opening the decision.

Two things I am carrying into the dispatch as constraints rather than leaving to inference:

1. This card does not get to re-litigate the decision. The deliverable is prose plus a prescription in the docs(spec): a form section / page component gates visibility only — say so, and tell disabled where it belongs (#7887) #8199 pattern, pointing authors at filtering the option out via per-option visibleWhen (ADR-0068 binds current_user there, which is what makes that the real answer on this surface). No key, no alias row — the same red line the mother ruling drew.
2. The escape hatch stays open and stated. Triage explicitly left real product pull for non-selectable field options as a future maintainer decision that widens the accepted set. The prose must not foreclose it — it should say what is true today and why, not that the answer can never change.

---

Generated by Claude Code

[os-zhuang]

Dispatch attempt 1 died with zero output — relaunching. Full evidence and reasoning on the sibling card, #8202 (comment 5276476195); this is the paired record so neither card carries a silent gap.

Short version: the agent stopped at launch (110-byte output stream, last written 04:02:56Z; no reachable agent; worktree created but clean, zero edits; no branch, no PR, no report). Nothing about this card was reached, so no premise re-check is owed and the triage measurement this card rests on is untouched. Claim, assignee and labels stand — attempt 2 is going out in the same action, so the card is genuinely dispatched rather than stranded.

---

Generated by Claude Code