[UoM prototype] Add measurement attribute support prototype (1/3)

[ricardotejedorsanz]

What this unblocks

This PR introduces the first public taxonomy package support for measurement-based attributes. Today, taxonomy attributes are effectively all closed-list attributes backed by predefined values. This change adds the minimum schema/model/dist support needed for attributes whose value is a measurement with supported units.

The goal of this first PR is to unblock downstream review and integration work with one concrete example, while keeping the broader vocabulary rollout and tooling work separated into follow-up PRs.

Example: Height on Bird Cage Accessories

This PR adds a new Height measurement attribute and assigns it to Animals & Pet Supplies > Pet Supplies > Bird Supplies > Bird Cage Accessories (ap-2-1-1).

In source data, it looks like:

- id: 12429
  name: Height
  description: Specifies the vertical measurement from bottom to top, determining space requirements and compatibility with other items.
  friendly_id: height
  handle: height
  type: measurement
  measurement_type: dimension
  supported_units:
  - cm
  - in

In the public dist attribute JSON, it emits as:

{
  "id": "gid://shopify/TaxonomyAttribute/12429",
  "name": "Height",
  "handle": "height",
  "type": "measurement",
  "measurement_type": "dimension",
  "supported_units": ["cm", "in"]
}

Category attribute references now also include the attribute type, so consumers can distinguish measurement attributes from closed-list attributes.

Explicit closed-list attributes

Since attributes are no longer all implicitly closed-list attributes, this PR makes the existing vocabulary explicit by adding:

type: closed_list

to existing base attributes, and by emitting:

"type": "closed_list"

in generated dist JSON for closed-list attributes and category attribute references.

Other changes in this package

To support this first measurement attribute package, this PR also updates:

• Ruby taxonomy attribute model loading and validation
• attribute data/dist serializers
• category dist serializer attribute references
• CUE schemas for source and generated dist files
• tests covering measurement attributes, explicit closed-list attributes, and generated dist output
• generated dist/en files

Measurement attributes require measurement_type and supported_units, and do not use predefined values.

Follow-ups

This PR intentionally keeps the scope to the first unblocker package. Follow-up stacked PRs will cover:

• the full measurement vocabulary rollout/alignment
• downstream dependency updates, including tooling such as the visualizer

[jeanguo-png]

Could we pass type, measurement_type, and supported_units from the base attribute into ExtendedAttribute? Right now an extended attribute based on a measurement attribute would default back to closed_list and lose its unit metadata. V0 does not include that case yet, but this would be easy to miss later.

Could we tighten the CUE schema so the attribute shape depends on type? closed_list should require values and disallow measurement metadata; measurement should require measurement_type/supported_units and disallow values. Ruby validation catches this today, but the schema should protect the public/source contract too.

[jeanguo-png]

Requesting changes for the measurement attribute contract edge cases:

• ExtendedAttribute should inherit type, measurement_type, and supported_units from its base attribute so future measurement-based extended attributes do not silently serialize as closed_list.
• The CUE schemas should make the shape depend on type: closed_list requires values and disallows measurement metadata; measurement requires measurement_type/supported_units and disallows values.

Ruby validation catches the current source data, but these should be enforced at the model/schema contract level before this becomes public.

[danielpgross]

Looks good overall 👍

Do we plan to define the closed set of allowed values for supported_units anywhere in this repo? I wouldn't consider it a blocker, just curious if you've thought about it.

[ricardotejedorsanz]

Thanks @jeanguo-png, addressed both blockers in a separate follow-up commit so the review changes are easy to inspect.

1. ExtendedAttribute now passes through type, measurement_type, and supported_units from the base attribute referenced by values_from. I added test coverage for both closed-list-backed and measurement-backed extended attributes.

2. The CUE schemas are now discriminated by type:

   • closed_list requires values and rejects measurement_type / supported_units
   • measurement requires measurement_type / supported_units and rejects values

I also updated the dist category attribute-ref schema to discriminate on type. Those refs remain intentionally lightweight, so they reject embedded values, measurement_type, and supported_units.

[ricardotejedorsanz]

Do we plan to define the closed set of allowed values for supported_units anywhere in this repo? I wouldn't consider it a blocker, just curious if you've thought about it.

Good question @danielpgross. For MVP I prefer to keep the public taxonomy contract lightweight: measurement attributes require supported_units, with the units we import already filtered to the MVP set that Core/Admin can support. I’d track any public unit display metadata or registry validation separately.

We will still need a Core-side mapping from taxonomy unit symbols to Core/Admin enums as part of the Core integration work. I’d keep that mapping out of this public taxonomy repo.

[jeanguo-png]

LGTM