You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Split out of #8251 — that card is scoped to the section family and its PR fixes only that. This is the neighbouring tab family in the same file, measured separately and deliberately not folded in.
content/docs/protocol/objectui/layout-dsl.mdx teaches two more key families that exist on no schema.
Against packages/spec/authorable-surface.base.json at origin/main (the generated authorable-surface anchor):
ui/ViewTab declares exactly nine authorable keys: filter, icon, isDefault, label, name, order, pinned, view, visible. No lazy, no source, no badge, no badgeVariant.
lazy returns 0 entries across the entire authorable surface. Positive control, same command shape: source returns 20 entries and badgeVariant 8 — the instrument plainly sees keys.
Every one of those 8 badgeVariant entries is on a NavItem surface (ui/ActionNavItem, ui/ComponentNavItem, ui/DashboardNavItem, ui/GroupNavItem, ui/ObjectNavItem, ui/PageNavItem, ui/ReportNavItem, ui/UrlNavItem) — app navigation, never a view tab. None of the 20 source entries is a tab or a section.
The page nests these tabs under layout: { mode: tabbed, tabs: [...] }. FormViewSchema.layout is a string enum (vertical / horizontal / inline / grid), not an object, and FormViewSchema declares no tabs key at all — so the wrapper is wrong independently of the leaf keys.
Prior art
The 2026-06 docs audit already flagged this family as unverified: docs/audits/2026-06-handwritten-docs-accuracy-followups.md records that "Tab/badge/wizard-steps YAML constructs … badgeVariant/badge:{count,variant} shapes may not exist in the spec", reported for follow-up rather than changed without evidence. This issue is that follow-up, now measured.
Suggested fix
Same shape as #8251's: remove or rewrite so the page describes only surfaces that exist. ⛔ Not by widening a schema — that would be a domain:spec contract change with its own lane and its own decision floor.
Split out of #8251 — that card is scoped to the section family and its PR fixes only that. This is the neighbouring tab family in the same file, measured separately and deliberately not folded in.
content/docs/protocol/objectui/layout-dsl.mdxteaches two more key families that exist on no schema.1. Tab-level
lazy/source(lines ~476-490, "Lazy-Loaded Tabs")2. Tab
badge/badgeVariant(lines ~492-507, "Tab Badges and Counters")Measurement
Against
packages/spec/authorable-surface.base.jsonatorigin/main(the generated authorable-surface anchor):ui/ViewTabdeclares exactly nine authorable keys:filter,icon,isDefault,label,name,order,pinned,view,visible. Nolazy, nosource, nobadge, nobadgeVariant.lazyreturns 0 entries across the entire authorable surface. Positive control, same command shape:sourcereturns 20 entries andbadgeVariant8 — the instrument plainly sees keys.badgeVariantentries is on a NavItem surface (ui/ActionNavItem,ui/ComponentNavItem,ui/DashboardNavItem,ui/GroupNavItem,ui/ObjectNavItem,ui/PageNavItem,ui/ReportNavItem,ui/UrlNavItem) — app navigation, never a view tab. None of the 20sourceentries is a tab or a section.ViewTabSchema(packages/spec/src/ui/view.zod.ts:872) is built withstrictObject, i.e.z.object(...).strict(), so these are parse rejections, not silent strips — the same behaviour empirically confirmed for the section family in docs: layout-dsl.mdx teaches section-levelvirtualScroll/itemHeight/lazy/renderStrategykeys that exist on no schema #8251's PR.Extra wrinkle: the wrapper shape is wrong too
The page nests these tabs under
layout: { mode: tabbed, tabs: [...] }.FormViewSchema.layoutis a string enum (vertical/horizontal/inline/grid), not an object, andFormViewSchemadeclares notabskey at all — so the wrapper is wrong independently of the leaf keys.Prior art
The 2026-06 docs audit already flagged this family as unverified:
docs/audits/2026-06-handwritten-docs-accuracy-followups.mdrecords that "Tab/badge/wizard-steps YAML constructs …badgeVariant/badge:{count,variant}shapes may not exist in the spec", reported for follow-up rather than changed without evidence. This issue is that follow-up, now measured.Suggested fix
Same shape as #8251's: remove or rewrite so the page describes only surfaces that exist. ⛔ Not by widening a schema — that would be a
domain:speccontract change with its own lane and its own decision floor.Generated by Claude Code