Documentation
Token Enforcement Settings
These settings control how token names and values are validated, and how version bumps are calculated when you publish. Configure them in your workspace settings under "Token naming" and "Versioning policy." Changes take effect immediately for everyone on your team.
Naming rules
A naming rule constrains the path or name of a token. Each rule uses one of three constraint types.
- •Required pattern — a regex tested against the last segment of the token path (the name after the final
/). Tokens whose name does not match fail the rule. - •Required prefix — the full token path must begin with this exact string. Use this to enforce namespace conventions, for example requiring all color tokens to start with
color/. - •Prohibited pattern — a regex tested against the full token path that must not match. Use this to ban legacy naming conventions or ad-hoc token names.
Each rule can be scoped to a specific token type: color, spacing, typography, shadow, or border-radius. When a type is set, the rule applies only to tokens of that type. When unset, it applies to all tokens.
Naming rules run automatically on every token save and again at publish time. Violations appear as "Naming violations" in the quality panel.
Example: two rules scoped by token type
// Require all color tokens to start with "color/"
{
requiredPrefix: "color/",
tokenType: "color"
}
// Require all spacing tokens to end in a numeric segment
{
requiredPattern: "\\d+$",
tokenType: "spacing"
}Format constraints
Format constraints validate the resolved value of a token, not its name. They are always scoped to a specific token type (tokenType is required). When a token's value does not match the constraint pattern, a "Format violation" is recorded. The message you set on the constraint is shown in the quality panel next to the affected token.
Use format constraints to enforce value conventions across your workspace, for example requiring all border-radius values to use rem units, or requiring all color values to be in hex format.
Format violations appear in the quality panel on every token save and at publish time. They do not block publish on their own, but they reduce the quality score.
Semver bump policy
By default, ReframeUI assigns version bumps based on the kind of change detected. You can tighten these defaults by adding rules that map a change kind to a minimum bump level. When a rule fires, that bump level is the floor for the publish. The final bump can only go up from there.
Change kinds
- •
token_removed— a token path was deleted from the design system - •
token_renamed— a token's path changed (it was moved or renamed) - •
token_value_changed— a token's resolved value changed with the same name and type - •
token_type_changed— a token's type changed, for example from color to spacing - •
component_removed— a component was deleted
Minimum bump levels
- •
minor— requires at least a minor version bump - •
major— requires at least a major version bump
Patch is always the baseline for value changes. A minimum bump setting can only raise the floor to minor or major, never lower it.
When multiple rules fire in a single publish, the highest required bump wins. You can raise the bump manually in the Studio publish dialog, but you cannot lower it below what your policy requires.
When reframe publish runs, the server evaluates the diff against your workspace's semver policy. If the --bump value is lower than the required minimum, the publish is rejected. The CLI prints which change kind required a higher bump and exits with a non-zero status.
Where violations surface
- •Quality panel in Studio — naming violations and format violations appear here after every token save, with a link to the affected token.
- •Publish gate in Studio — all quality checks run again at publish time. Naming violations configured as blocking prevent the publish from completing.
- •CLI publish — semver policy violations cause
reframe publishto exit with a non-zero status and a message identifying which change kind required a higher bump. Naming and format violations are reported as warnings in the CLI output but do not gate the publish unless they are configured as blocking.
For the full quality check breakdown, see Quality and Accessibility. For the publish flow and confirmation dialog, see Publishing. For publish flags and CLI options, see CLI Reference.