[finding] `disabled` has no vocabulary at all on FormSectionSchema / PageComponentSchema — no readonly/disabled/disabledWhen key to point an author at

[os-zhuang]

Recorded from PR #7884's report (out_of_scope_finding 2 of card #7832; filed by the PM seat because the cloud dev session cannot write issues). Filed unassigned — a recording, not a claim.

Observation, measured on the #7884 branch against origin/main

While curating alias/guidance rows for visible/showWhen/disabled on the visibleWhen-family shapes (#7832), the dev found that FormSectionSchema and PageComponentSchema (and SelectOptionSchema) declare no disabled-ish key whatsoever — no disabled, no disabledWhen, no readonly. There is no way to express "this section / page component is disabled/read-only" in view/page metadata.

Consequence for #7832's scope: disabled written on those shapes is rejected loudly (strict shapes) but with no pointer, because there is nothing on the shape to point at — an alias row would name a key the shape rejects next (alias-integrity.test.ts fails such a row outright). PR #7884 pinned these as deliberate gaps: visible-when-alias-guidance.test.ts section 3 fails if any of the three shapes ever gains a disabled-ish key, so the owed alias row becomes visible the moment it becomes writable.

The question

Whether this is a deliberate design boundary (sections/components gate visibility only; disabling is a field-level concern via readonly/readonlyWhen) or a vocabulary gap is an acceptance-surface question for domain:spec, not for the surface seat — adding any such key would widen the accepted metadata set.

If it is ruled a boundary: worth one sentence of prose on the shapes saying so (that half would return to domain:spec-surface). If it is ruled a gap: the #7884 tripwire pins already mark where the alias rows become owed.

Refs

#7832 / PR #7884 (provenance, tripwire pins), #7816 (canonical-spelling question, related vocabulary), #7751 (page-component props passthrough — adjacent but distinct: that is about the properties bag, this is about the shape's own keys).

Dedup: searched open issues for FormSectionSchema/PageComponentSchema + disabled/readonly vocabulary — nothing beyond the refs above.

[hotlong]

Triage: routed domain:spec (the question is an acceptance-surface one — any disabled-ish key on FormSectionSchema/PageComponentSchema/SelectOptionSchema widens the accepted metadata set); hold as finding. Zero measured author pull today (the gap surfaced from alias-row curation, not from anyone trying to author a disabled section), and the #7884 tripwire pins already make the owed alias rows visible the moment any of the three shapes gains such a key — the guard exists, so waiting costs nothing.

Startup-scope reading: default is defer, don't declare — vocabulary added without pull is a permanent maintenance obligation. If the spec seat instead wants to rule it a deliberate boundary ("sections/components gate visibility only; disabling is field-level"), that ruling is a one-sentence prose addition on the shapes (that half re-routes domain:spec-surface) and would close this card.

Restart conditions: (a) measured author demand (a real app or Studio flow needing a disabled section/component); (b) the spec seat electing to write the boundary ruling; (c) either sibling decision (#7816 canonical spelling) landing in a way that touches this vocabulary family.

---

Generated by Claude Code

[hotlong]

Finding-grading round: escalated to needs-user-decision (domain:spec) — the zero-pull assessment is stale by one day: #7816 is queued work whose ask 1 names the section/component shapes for a disabled → disabledWhen alias, a row those shapes would reject (alias-integrity.test.ts fails outright, and §3 of visible-when-alias-guidance.test.ts pins the rejection). #7816 has been marked pm:blocked on this card.

Question: is the absence of disabled/readonly on FormSectionSchema / PageComponentSchema a boundary (sections/components gate visibility only — document it, alias rows stay off) or a gap (add the slot + alias)?

Four-prong analysis:

• Platform long-term coherence: sections/components have no editability semantics today — a readonly slot on them would be declared-but-unenforced from day one, the exact ADR-0049 class the repo is retiring elsewhere.
• Measured business pull: One intent, two spellings: visible (actions) vs visibleWhen (fields / sections / userActions) — and the alias guard only covers one direction #7816's ask is author-confusion-driven (better error messages), not capability-driven; no author has asked for section-level disabling itself.
• AI-agent error-resistance: loud rejection already works; ruling "boundary" + a guidance string telling authors where the key DOES belong is strictly clearer than accepting a key the runtime ignores.
• Startup scope discipline: boundary = one sentence of prose per shape; gap = new enforced surface across two schemas plus renderer work.

Recommendation: boundary — document on both shapes ("visibility only; editability lives on fields"), which re-routes the fix domain:spec-surface, keeps acceptance unchanged, and unblocks #7816 immediately (its disabled arm becomes guidance-text-only; note field.zod.ts:464 already records fields take readonlyWhen, so #7816's alias target needs that correction either way). When ruled, return #7816 to pm:queue in the same action.

---

Generated by Claude Code