Found while verifying #7816's ask 1 (which #7832 / PR #7884 delivered). #7832 curated six shapes; its inventory test packages/spec/src/shared/visible-when-alias-guidance.test.ts pins those six. Two other shapes in packages/spec declare visibleWhen and were never in that inventory — on both, an author who writes the action-side spelling still gets a rejection that names the surface but never names the key to write instead. That is exactly the defect #7832 existed to remove, just on surfaces nobody enumerated.
Measured on origin/main @ 84c07c3c1, freshly built spec dist
1. page:tabs item — packages/spec/src/ui/component.zod.ts (PageTabsProps, items array, visibleWhen declared ~L601)
ACCEPTED items[0].visibleWhen (canonical — landing key confirmed)
BARE items[0].visible
Unrecognized key(s) on this `page:tabs` item: `visible`. Until #4001 batch A an
undeclared prop was dropped in silence: …
BARE items[0].showWhen (same message shape)
2. ScreenFieldConfigSchema — packages/spec/src/automation/builtin-node-config.zod.ts (visibleWhen declared ~L404)
ACCEPTED { name: 'f', visibleWhen: 'record.x' } (canonical — landing key confirmed)
BARE { name: 'f', visible: true }
Unrecognized key(s) on this screen field: `visible`. Until #4001 an undeclared key
here was dropped at the execute-time parse — …
BARE { name: 'f', showWhen: 'record.x' } (same message shape)
Neither message mentions visibleWhen. Compare the six shapes #7832 did cover, all of which now name a target key (RowCrudActionOverrideSchema, FieldSchema, SelectOptionSchema, FormFieldSchema, FormSectionSchema, PageComponentSchema).
Suggested fix
Both shapes have exactly ONE landing key for the visibility intent and no boolean sibling, so by the rule visible-when-alias-guidance.test.ts states in its header (one landing key ⇒ alias; two ⇒ guidance prose; none ⇒ nothing) both are the simple alias case: visible → visibleWhen, showWhen → visibleWhen. Acceptance stays byte-identical — an alias row is a message channel, not a parse-time rename.
Two constraints inherited from #8199, both worth re-checking at implementation time:
The natural home for the pins is a fourth section in visible-when-alias-guidance.test.ts, so the inventory stays the single place that says which surfaces are answered and which are deliberately not.
Scope note
Filed unassigned, out of scope for #7816 — that card's declared file surface is data/object.zod.ts / data/field.zod.ts / the shared strict-options plumbing, and neither file above is on it.
Refs #7816 (parent question), #7832 / #7884 (the sweep this completes), #7889, #8199.
Found while verifying #7816's ask 1 (which #7832 / PR #7884 delivered). #7832 curated six shapes; its inventory test
packages/spec/src/shared/visible-when-alias-guidance.test.tspins those six. Two other shapes inpackages/specdeclarevisibleWhenand were never in that inventory — on both, an author who writes the action-side spelling still gets a rejection that names the surface but never names the key to write instead. That is exactly the defect #7832 existed to remove, just on surfaces nobody enumerated.Measured on
origin/main@84c07c3c1, freshly built specdist1.
page:tabsitem —packages/spec/src/ui/component.zod.ts(PageTabsProps, items array,visibleWhendeclared ~L601)2.
ScreenFieldConfigSchema—packages/spec/src/automation/builtin-node-config.zod.ts(visibleWhendeclared ~L404)Neither message mentions
visibleWhen. Compare the six shapes #7832 did cover, all of which now name a target key (RowCrudActionOverrideSchema,FieldSchema,SelectOptionSchema,FormFieldSchema,FormSectionSchema,PageComponentSchema).Suggested fix
Both shapes have exactly ONE landing key for the visibility intent and no boolean sibling, so by the rule
visible-when-alias-guidance.test.tsstates in its header (one landing key ⇒ alias; two ⇒ guidance prose; none ⇒ nothing) both are the simple alias case:visible → visibleWhen,showWhen → visibleWhen. Acceptance stays byte-identical — an alias row is a message channel, not a parse-time rename.Two constraints inherited from #8199, both worth re-checking at implementation time:
guidanceSetmatch consumes a key before the alias channel, so a set and an alias row matching the same key are not additive. Neither shape here spreadsVISIBILITY_STRICT_OPTIONS(they are hand-rolledstrictObjectcalls with their own options), so no set currently shadows these keys — but verify, oralias-integrity.test.ts's [finding] alias-integrity cannot see an alias row made unreachable by a guidanceSet — a vis-shaped alias on VISIBILITY_STRICT_OPTIONS surfaces would be dead code with no gate saying so #7889 reachability check will go red on a dead row.VISIBILITY_STRICT_OPTIONS: that table may carry only what is true of all three of its consumers.The natural home for the pins is a fourth section in
visible-when-alias-guidance.test.ts, so the inventory stays the single place that says which surfaces are answered and which are deliberately not.Scope note
Filed unassigned, out of scope for #7816 — that card's declared file surface is
data/object.zod.ts/data/field.zod.ts/ the shared strict-options plumbing, and neither file above is on it.Refs #7816 (parent question), #7832 / #7884 (the sweep this completes), #7889, #8199.