feat(spec): configurable name-object field catalog

[GarthDB]

Summary

The current spec hardcodes 13 semantic fields + 3 dimension fields on the token name object. Every time a design system needs a new concept category (typography script, component style, scaleIndex), the spec itself must change. The token-spec-gap-analysis identified 6 proposals for new fields — and that's just Spectrum. Other design systems would have entirely different concept categories.

Proposal: Make the name object schema-configurable via a field declaration mechanism, so design systems declare their own concept categories, vocabulary, and validation rules.

Motivation

The spec already has a great extensibility pattern in the dimension declaration system — you declare an axis name, its allowed modes, and a default. We should apply this same pattern to all name-object fields.

Currently hardcoded in:

• token.schema.json — nameObject properties (13 semantic + 3 dimension)
• manifest.schema.json — conceptOrder enum (13 values)
• sdk/core/src/validate/spec009.rs — ENUM_CHECKED_FIELDS
• sdk/core/src/query.rs — NAME_OBJECT_KEYS
• sdk/core/src/registry.rs — for_field() match statement

Proposed design: Field declarations

A new field.schema.json for declaring name-object fields:

{
  "name": "style",
  "description": "Visual treatment or presentation style",
  "kind": "semantic",
  "registry": "styles.json",
  "validation": "advisory",
  "serialization": { "position": 13 },
  "scope": null,
  "required": false,
  "valueType": "string"
}

Each design system ships a field catalog — a set of these declarations. Spectrum's current 13+3 fields become Spectrum's default catalog. The spec defines the mechanism, not the fields themselves.

Tech analogies considered

• CSS @property — declare custom properties with type, initial value, inheritance
• GraphQL schema — each schema declares its own types; engine validates against declarations
• JSON Schema vocabularies — separate structural validation from keyword definitions
• Protobuf field numbers — serialization.position is analogous
• Database column catalog — the information_schema pattern

Key properties of a field declaration

Field	Type	Description
name	string	Key on the name object
kind	semantic / dimension	Whether it participates in cascade
registry	string or null	Registry file for vocabulary validation
validation	strict / advisory / none	Error vs. warning vs. skip
serialization.position	integer	Default serialization order
scope	string or null	Token-type scope (e.g., typography)
required	boolean	Required on every name object?
valueType	string / integer	Value type constraint

Impact

• All 6 proposals from feat: token-to-spec gap analysis, registry expansion, scaleIndex field, and spec proposals #814 become simple field-declaration additions
• Other design systems can define their own fields without forking the spec
• Validation stays fast (catalog loaded once, HashMap lookups)
• Platform manifests can reference declared fields for formatting

Migration path

1. Create field.schema.json + Spectrum's field catalog (additive)
2. Update tools to read catalog instead of hardcoding
3. Update manifest schema — conceptOrder validates against catalog
4. Reframe taxonomy.md as the mechanism spec

Related

• feat: token-to-spec gap analysis, registry expansion, scaleIndex field, and spec proposals #814 — token-spec-gap-analysis (identified the need)
• Proposals 001-006 in docs/proposals/
• packages/design-data-spec/spec/taxonomy.md
• packages/design-data-spec/schemas/dimension.schema.json (existing extensibility pattern)