Status: Phase 1 stub. Matures in Phase 5 per §8.1.

Statement

Primitives are named with nouns, not noun-phrases or hybrid verb-nouns. The name describes what the thing is, not what it does or what role it plays in some specific layout. Component names map to design-vocabulary terms a designer would recognise without reading code.

Why

The audit ledger found 14 components whose names were either layout-bound (HeroMetaGrid, DiagnosticsTopbar) or role-bound (ActionButton, TrustRow). Layout-bound names break when the same primitive appears in a non-grid context. Role-bound names create ambiguity when a second role appears: is <TrustRow> for trust, or for help, or for both? The audit answer was: it ended up doing both, badly, because the name made the second role feel like a violation.

Noun-only names force the right question at use-site: "is this primitive the right thing for this content?" rather than "do I need to invent a sibling primitive because this one's name doesn't fit?"

How

The Phase 1 Track B renames already executed in §4.2 directory layout:

EyebrowTag → <Eyebrow>
CanonicalIcon → <SymbolTile>
HeroMetaGrid → <HeroMeta>
IssueRibbon → <IssueBadge>
ActionButton → <Button>
TrustRow + HelpRow → <MetaRow> with variant prop
DiagnosticsTopbar → <OperatorBar>

PR #1 onward enforces the new names. ESLint catches imports of the legacy names via a deprecation rule (Phase 2).

Phase 5 deepens this stub with per-rename rationale and the decision-tree for naming new primitives.