@wix/web5-token-contract

Which theme tokens a platform may import, and who wins when a template disagrees.

Data only — no runtime dependencies. That is the point: embed-loader is the first script on a merchant's page and declares one dependency, so it cannot reach into @wix/web5-core (eleven dependencies, plus a react peer) to read a list of nineteen strings.

import { BRAND_TOKENS, bucketOf, hostAliasFor } from '@wix/web5-token-contract';

bucketOf('--primary');            // 'brand' → written directly, the store wins
bucketOf('--radius');             // 'host'  → written as an alias, the template wins
bucketOf('--anything-unknown');   // 'host'  → the safe default
hostAliasFor('--radius');         // '--web5-host-radius'

The two buckets

The split is about who wins, not about what may be imported. An adapter may read anything the store states; the bucket decides what happens when a template has an opinion about the same token.

| Bucket | Written as | When a template also sets it | |---|---|---| | brand | the real token, last | the store wins — templates may not set these | | host | --web5-host-<name> | the template wins; the import is only a default |

A token absent from the contract is treated as host. That is deliberate: an alias nothing consumes renders nothing, so an adapter reading a token nobody has classified cannot override a template by accident.

Consumers

• embed-loader — composes the runtime stylesheet
• web5-core — wires the --web5-host-* aliases its stylesheets consume
• the seed's validate-templates — fails a template that sets a brand token
• the shop owner's panel — renders a control per editable entry

Rationale and the full precedence design: DL #193.