SLASHED

Version Freeze Policy

Status: ACTIVE — The project is frozen at 0.6.x.x. Enforced since: v0.6.28.0 (2026-05-11). Last reviewed: v0.6.30.0.

What is frozen

The MAJOR version digit (second position in 0.MAJOR.MINOR.PATCH) is locked at 6. No bump to 0.7.0.0 or higher is permitted until every unlock condition below is satisfied.

Within 0.6.x.x, normal development continues:

MINOR bumps (0.6.28.0, 0.6.29.0, …) — new tokens, utilities, components.
PATCH bumps (0.6.28.1, 0.6.28.2, …) — bugfixes, doc corrections.

The version ceiling is enforced by bin/bump-version.sh — it will reject any target version ≥ 0.7.0.0 unless a FREEZE_UNLOCK file exists in the repo root.

Why this freeze exists

The token and variable system is the foundation of everything in SLASHED. Every component, every utility, every consumer override depends on token names being correct, complete, and DX-friendly.

Rushing to 0.7.0.0 (the token freeze milestone per ROADMAP.md) before the system is battle-tested would lock in naming mistakes, coverage gaps, and DX friction permanently. Once 0.7.0.0 ships, token names become stable API — renames require deprecation aliases with overlap, and removals must wait for 0.8.0.0.

The cost of premature freeze is higher than the cost of staying at 0.6.x.x.

Unlock conditions

ALL of the following must be true before 0.7.0.0 can ship:

1. Token completeness

Every category in bin/check-token-parity.sh passes at “expected” level (not just minimum — the minimum is the floor, not the goal).
No token naming inconsistencies (audited by maintainer).
Token names follow the DX contract in PHILOSOPHY.md: predictable, discoverable, composable, consistent scale steps.
tokens-user.example.css covers every configurable root with clear comments and grouped sections.

2. Token testing

At least 3 real-world templates built end-to-end on the token system: - Marketing/landing page - Article/blog/documentation page - Dashboard/admin/form-heavy page
Each template authored without !important, without custom CSS for what should be a token, and without “missing-by-analogy” gaps.
Dark mode verified on all 3 templates (automatic via light-dark()).
Token override workflow tested: copy tokens-user.example.css, change 3–5 root values, verify the entire system responds correctly.

3. DX parity validation

A developer familiar with Tailwind can find equivalent capability for every common pattern without leaving the token system.
A developer familiar with Bootstrap can map their mental model to SLASHED tokens without documentation friction.
The cheatsheet.html search covers every token by name and by purpose (e.g., searching “shadow” finds all shadow tokens).

4. Documentation completeness

docs/TOKENS.md fully documents every token group with examples.
Every token appears in cheatsheet.html (enforced by CI).
configurator.html supports visual customization of all configurable roots (brand colors, spacing scale, typography scale).

5. Naming audit

No abbreviation inconsistencies (e.g., mixing bg and background).
Scale steps are uniform: 2xs/xs/s/m/l/xl/2xl/3xl everywhere.
Prefix consistency: all tokens use --sf- prefix.
No naming collisions with common consumer patterns.

6. Philosophy compliance

bin/check-philosophy-drift.sh passes with zero violations.
bin/check-token-parity.sh passes at expected coverage levels.
All 7 pillars are respected by the token system design.

How to unlock

When all conditions above are verified:

Check every box in this document (edit this file, commit).

Run the full verification suite:

bin/sync-docs.sh
bin/check-token-parity.sh --verbose --report
bin/check-philosophy-drift.sh

Create FREEZE_UNLOCK in the repo root with the following content:

Freeze unlock authorized.
All conditions in docs/VERSION-FREEZE.md verified.
Signed: [maintainer name]
Date: [YYYY-MM-DD]

Run bin/bump-version.sh 0.7.0.0.
After the bump succeeds, delete FREEZE_UNLOCK (it’s a one-time gate).
Commit everything as: chore(release): bump version to v0.7.0.0 — token freeze

After unlock: what 0.7.0.0 means

Per ROADMAP.md, at 0.7.0.0:

Token names are frozen. Every --sf-* design custom property in tokens-default.css becomes stable API.
Utility class names are frozen. Everything in slashed-utilities.css becomes stable API.
Additions remain possible. New tokens and utilities can be added.
Renames require deprecation. A rename must ship a deprecation alias with at least one MINOR of overlap before the old name is removed.
Removals wait for 0.8.0.0.

Component classes (.sf-*), instance tokens (--sf-btn-bg, etc.), and the JS API stay mutable until 0.8.0.0.

FAQ

Q: What if we discover a token naming issue at 0.6.45.0? A: Fix it. That’s exactly why we’re frozen — free renames are possible in 0.6.x.x with no deprecation overhead. After 0.7.0.0 that freedom is gone.

Q: How long will this freeze last? A: As long as it takes. There is no calendar deadline. Quality over speed.

Q: Can the freeze be bypassed for urgent reasons? A: No. The FREEZE_UNLOCK mechanism is the only path. If it’s truly urgent, complete the unlock conditions — that’s the fastest path.

Q: What about the blueprint library? A: Blueprints have their own versioning. They are content, not API. The framework version freeze does not affect blueprint releases.

This site is open source. Improve this page.