refactor: rename project and update references to "variables-contract"

- Changed project name from "variable-contract" to "variables-contract" across all relevant files, including configuration, documentation, and links.
- Updated basePath in docmd.config.js to reflect the new project name.
- Ensured consistency in naming throughout the documentation and examples.
- Removed obsolete site files to streamline the project structure.

Author: marklearst

README.md

@@ -1,18 +1,18 @@
-# Variable Contract
+# Variables Contract
 
 Public specification and governance standard for design variables. DTCG 2025.10 compliant format with naming rules, validation requirements, versioning strategy, and adapter patterns.
 
 **Version:** 0.3.5
 **Status:** Draft
 **Editor:** Mark Learst
 
-Variables are variables. CSS variables, JavaScript variables, Figma variables. Variable Contract standardizes how we name, structure, and govern them. No metaphors. No cute names. Just variables.
+Variables are variables. CSS variables, JavaScript variables, Figma variables. Variables Contract standardizes how we name, structure, and govern them. No metaphors. No cute names. Just variables.
 
 If variables are managed without a contract, you get silent renames, broken references, inconsistent naming, tool lock-in, and production failures.
 
 ## What this is
 
-Variable Contract defines:
+Variables Contract defines:
 
 - JSON structure (DTCG 2025.10 format)
 - Naming convention (dot-separated paths, lowercase, no platform prefixes)
@@ -21,7 +21,7 @@ Variable Contract defines:
 - Versioning strategy (semantic versioning, breaking change definitions)
 - Adapter patterns (Figma, Tokens Studio, Style Dictionary)
 
-Variable Contract does NOT define:
+Variables Contract does NOT define:
 
 - Variable values (your design decisions)
 - Tools to use (works with any DTCG-compliant tool)
@@ -32,7 +32,7 @@ Variable Contract does NOT define:
 
 Variables are variables. CSS variables, JavaScript variables, Figma variables. They store values, can be referenced, and can be changed.
 
-"Design tokens" creates confusion. Developers know variables. Designers know variables. Variable Contract uses the term everyone understands.
+"Design tokens" creates confusion. Developers know variables. Designers know variables. Variables Contract uses the term everyone understands.
 
 See [Why Variables](docs/introduction/why-variables) for the full argument.
 
@@ -42,35 +42,35 @@ See [Why Variables](docs/introduction/why-variables) for the full argument.
 
 Everyone calls them something different: design tokens, style properties, design constants, variables, tokens. This creates confusion and separation between design and code.
 
-Variable Contract standardizes on "variables" and provides clear naming rules.
+Variables Contract standardizes on "variables" and provides clear naming rules.
 
 ### No governance
 
 Variables change without rules. Renames break components. Invalid references ship to production. Breaking changes go unnoticed.
 
-Variable Contract provides governance: naming rules, validation requirements, versioning strategy, change control process.
+Variables Contract provides governance: naming rules, validation requirements, versioning strategy, change control process.
 
 ### Tool lock-in
 
 Variables are tied to specific tools. Figma exports don't work with Style Dictionary. Tokens Studio format doesn't match DTCG. Migration is painful.
 
-Variable Contract is tool-agnostic. Use any tool. Adapters normalize tool outputs to the contract.
+Variables Contract is tool-agnostic. Use any tool. Adapters normalize tool outputs to the contract.
 
 ### Handoff breaks
 
 Design and code don't align. Designers create variables in Figma. Developers consume CSS variables. The connection breaks.
 
-Variable Contract bridges the gap. Variables flow from Figma through adapters to version control to generated outputs.
+Variables Contract bridges the gap. Variables flow from Figma through adapters to version control to generated outputs.
 
 ### No validation
 
 Invalid variables ship to production. Broken references break components. Type mismatches cause runtime errors.
 
-Variable Contract requires validation. CI checks catch errors before they ship.
+Variables Contract requires validation. CI checks catch errors before they ship.
 
 ## DTCG 2025.10 compliance
 
-Variable Contract is DTCG 2025.10 compliant. Any JSON file that follows Variable Contract rules is valid DTCG 2025.10 format.
+Variables Contract is DTCG 2025.10 compliant. Any JSON file that follows Variables Contract rules is valid DTCG 2025.10 format.
 
 What DTCG provides:
 
@@ -81,7 +81,7 @@ What DTCG provides:
 - Group extension with `$ref`
 - Mode support
 
-What Variable Contract adds:
+What Variables Contract adds:
 
 - Naming convention rules
 - Change control process
@@ -93,7 +93,7 @@ See [DTCG Alignment](docs/contract/dtcg-alignment) for details.
 
 ## Quick start
 
-### For teams adopting Variable Contract
+### For teams adopting Variables Contract
 
 1. Read [Getting Started](docs/adoption/getting-started)
 2. Set up repository structure (`tokens/` directory)
@@ -134,8 +134,8 @@ See [Implementation Checklist](docs/adoption/implementation-checklist) for compl
 ### Introduction
 
 - [Why Variables](docs/introduction/why-variables) - Why "variables" not "design tokens"
-- [Comparison](docs/introduction/comparison) - Variable Contract vs DTCG, Style Dictionary, Material, Adobe
-- [Positioning](docs/introduction/positioning) - What Variable Contract is and is not
+- [Comparison](docs/introduction/comparison) - Variables Contract vs DTCG, Style Dictionary, Material, Adobe
+- [Positioning](docs/introduction/positioning) - What Variables Contract is and is not
 
 ### Contract reference
 
@@ -173,7 +173,7 @@ See [Implementation Checklist](docs/adoption/implementation-checklist) for compl
 
 ### Tooling
 
-- [Ecosystem](docs/tooling/ecosystem) - Tools that support Variable Contract
+- [Ecosystem](docs/tooling/ecosystem) - Tools that support Variables Contract
 - [CI/CD](docs/tooling/ci-cd) - CI/CD integration patterns
 - [Build Pipelines](docs/tooling/build-pipelines) - Complete build pipeline examples
 - [Figma Adapter](docs/adapters/figma) - Figma export normalization
@@ -206,7 +206,7 @@ See [Implementation Checklist](docs/adoption/implementation-checklist) for compl
 
 ## Requirements
 
-Variable Contract JSON files MUST:
+Variables Contract JSON files MUST:
 
 - Use DTCG 2025.10 format
 - Follow naming convention (dot-separated paths, lowercase, no platform prefixes)
@@ -216,7 +216,7 @@ Variable Contract JSON files MUST:
 - Avoid circular references
 - Use consistent mode keys within collections
 
-Variable Contract JSON files SHOULD:
+Variables Contract JSON files SHOULD:
 
 - Include `$description` when intent is not obvious
 - Use semantic aliases for UI consumption
@@ -227,7 +227,7 @@ See [Validation Checklist](docs/governance/validation) for complete requirements
 
 ## Validation
 
-Variable Contract requires validation at multiple points:
+Variables Contract requires validation at multiple points:
 
 1. After adapter normalization (check structure, naming, references)
 2. In CI on every PR (block invalid changes)
@@ -248,7 +248,7 @@ See [Validation](docs/governance/validation) for validation tools and CI setup.
 
 ## Versioning
 
-Variable Contract uses semantic versioning (MAJOR.MINOR.PATCH):
+Variables Contract uses semantic versioning (MAJOR.MINOR.PATCH):
 
 - MAJOR: breaking changes (renames, removals, type changes)
 - MINOR: new variables, new modes, non-breaking additions
@@ -271,7 +271,7 @@ See [Versioning](docs/governance/versioning) for complete versioning strategy.
 
 ## Adapters
 
-Adapters normalize tool outputs into Variable Contract format.
+Adapters normalize tool outputs into Variables Contract format.
 
 ### Figma adapter
 
@@ -298,7 +298,7 @@ See [Tokens Studio Adapter](docs/adapters/tokens-studio) for details.
 
 ### Style Dictionary adapter
 
-Generates platform outputs from Variable Contract JSON:
+Generates platform outputs from Variables Contract JSON:
 
 - CSS variables
 - TypeScript types
@@ -316,28 +316,28 @@ See [Style Dictionary Adapter](docs/adapters/style-dictionary) for details.
 
 ## UMP context
 
-Variable Contract is part of UMP (UI Mapping Protocol), a larger system for mapping design and development artifacts.
+Variables Contract is part of UMP (UI Mapping Protocol), a larger system for mapping design and development artifacts.
 
 UMP components:
 
-- Variable Contract (this spec) - variables/tokens
+- Variables Contract (this spec) - variables/tokens
 - Component Contract (future) - component mapping
 - Pattern Contract (future) - pattern mapping
 - Design-Dev Mapping (future) - artifact relationships
 
-Variable Contract is the first piece of UMP, focusing on variables.
+Variables Contract is the first piece of UMP, focusing on variables.
 
 ## Status
 
-Variable Contract is:
+Variables Contract is:
 
 - DTCG 2025.10 compliant
 - Production-ready
 - Tool-agnostic
 - Validated in CI
 - Used by teams
 
-Variable Contract is NOT:
+Variables Contract is NOT:
 
 - A W3C standard (uses DTCG format)
 - A tool (works with existing tools)
@@ -346,7 +346,7 @@ Variable Contract is NOT:
 
 ## Failure modes
 
-If Variable Contract is not used:
+If Variables Contract is not used:
 
 - Silent renames break components
 - Broken references cause production failures
@@ -355,7 +355,7 @@ If Variable Contract is not used:
 - No validation allows invalid variables to ship
 - Versioning chaos makes upgrades risky
 
-If Variable Contract is used incorrectly:
+If Variables Contract is used incorrectly:
 
 - Skipping validation allows invalid variables to ship
 - Not following naming convention breaks code generation
@@ -365,7 +365,7 @@ If Variable Contract is used incorrectly:
 
 ## Contributing
 
-Variable Contract is a public specification. Contributions welcome.
+Variables Contract is a public specification. Contributions welcome.
 
 Before contributing:
 
@@ -405,11 +405,11 @@ Generates static site in `site/`.
 
 **Editor:** Mark Learst
 
-Variable Contract is maintained by the editor. Contributions welcome.
+Variables Contract is maintained by the editor. Contributions welcome.
 
 ## Acknowledgments
 
-Variable Contract builds on:
+Variables Contract builds on:
 
 - [DTCG 2025.10 Format](https://www.designtokens.org/tr/2025.10/format/) - Base format specification
 - [Style Dictionary](https://styledictionary.com/) - Output generation tool
@@ -419,12 +419,12 @@ Variable Contract builds on:
 ## References
 
 - [DTCG 2025.10 Specification](https://www.designtokens.org/tr/2025.10/format/) - Design Tokens Community Group format
-- [Variable Contract Documentation](docs/index.md) - Complete specification and governance
+- [Variables Contract Documentation](docs/index.md) - Complete specification and governance
 - [DTCG Alignment](docs/contract/dtcg-alignment.md) - Compliance details
 
 ## Conformance
 
-To claim Variable Contract compliance:
+To claim Variables Contract compliance:
 
 1. Use DTCG 2025.10 format for variable JSON
 2. Follow naming convention (dot-separated paths, lowercase, no platform prefixes)

docmd.config.js

@@ -1,11 +1,11 @@
 // docmd.config.js: basic config for docmd
-// basePath is "/variable-contract" for GitHub Pages
+// basePath is "/variables-contract" for GitHub Pages
 // Vercel deploys from gh-pages branch (same build) and uses rewrites
-const basePath = "/variable-contract";
-const siteUrl = "https://marklearst.github.io/variable-contract";
+const basePath = "/variables-contract";
+const siteUrl = "https://marklearst.github.io/variables-contract";
 
 module.exports = {
-  siteTitle: "Variable Contract",
+  siteTitle: "Variables Contract",
   srcDir: "docs",
   outputDir: "site",
   basePath,

docs/adapters/figma.md

@@ -212,7 +212,7 @@ After:
 
 ### Step 6: Validate naming
 
-Check that normalized names follow Variable Contract naming convention (see [Naming](/variable-contract/adapters/contract/naming)).
+Check that normalized names follow Variable Contract naming convention (see [Naming](/variables-contract/adapters/contract/naming)).
 
 - Names MUST use dot-separated paths
 - Names MUST be lowercase
@@ -354,12 +354,12 @@ Designers author variables in Figma. Changes flow through export, normalization,
 2. Design Engineer runs Figma adapter to normalize export JSON.
 3. Design Engineer commits normalized JSON to version control.
 4. Design Engineer opens PR for review.
-5. Reviewers check naming, types, references (see [Change Control](/variable-contract/adapters/governance/change-control)).
+5. Reviewers check naming, types, references (see [Change Control](/variables-contract/adapters/governance/change-control)).
 6. After merge, CI generates build outputs.
 
 ### What gets reviewed
 
-- Variable names follow naming convention ([Naming](/variable-contract/adapters/contract/naming))
+- Variable names follow naming convention ([Naming](/variables-contract/adapters/contract/naming))
 - References resolve correctly
 - Modes are limited (`light`, `dark`)
 - No duplicate values when base tokens exist

docs/adapters/index.md

@@ -69,10 +69,10 @@ If adapters fail:
 
 ## Adapter documentation
 
-- [Figma Adapter](/variable-contract/adapters/figma) - Figma Variables export normalization
-- [Tokens Studio Adapter](/variable-contract/adapters/tokens-studio) - Tokens Studio export normalization
-- [Style Dictionary Adapter](/variable-contract/adapters/style-dictionary) - Variable Contract to CSS/TypeScript/etc.
-- [Tailwind Adapter](/variable-contract/adapters/tailwind) - Tailwind theme configuration generation
+- [Figma Adapter](/variables-contract/adapters/figma) - Figma Variables export normalization
+- [Tokens Studio Adapter](/variables-contract/adapters/tokens-studio) - Tokens Studio export normalization
+- [Style Dictionary Adapter](/variables-contract/adapters/style-dictionary) - Variable Contract to CSS/TypeScript/etc.
+- [Tailwind Adapter](/variables-contract/adapters/tailwind) - Tailwind theme configuration generation
 
 ## Out of scope
 

docs/adapters/tokens-studio.md

@@ -74,7 +74,7 @@ This format is already correct. No transformation needed.
 
 ### Step 4: Validate naming
 
-Check that names follow Variable Contract naming convention (see [Naming](/variable-contract/adapters/contract/naming)).
+Check that names follow Variable Contract naming convention (see [Naming](/variables-contract/adapters/contract/naming)).
 
 - Names MUST use dot-separated paths
 - Names MUST be lowercase
@@ -204,12 +204,12 @@ Designers author variables in Figma using Tokens Studio plugin. The repo JSON is
 2. Design Engineer validates export JSON (run adapter if needed).
 3. Design Engineer commits JSON to version control.
 4. Design Engineer opens PR for review.
-5. Reviewers check naming, types, references (see [Change Control](/variable-contract/adapters/governance/change-control)).
+5. Reviewers check naming, types, references (see [Change Control](/variables-contract/adapters/governance/change-control)).
 6. After merge, CI validates JSON and generates build outputs.
 
 ### What gets reviewed
 
-- Variable names follow naming convention ([Naming](/variable-contract/adapters/contract/naming))
+- Variable names follow naming convention ([Naming](/variables-contract/adapters/contract/naming))
 - References resolve correctly
 - Token organization (base, semantic, component layers)
 - Breaking changes are documented
@@ -232,7 +232,7 @@ Before exporting from Tokens Studio:
 - Semantic aliases: reference base tokens, describe usage
 - Component tokens: reference semantic aliases, component-scoped
 
-See [Anatomy](/variable-contract/adapters/contract/anatomy) for details.
+See [Anatomy](/variables-contract/adapters/contract/anatomy) for details.
 
 ### Artifacts that change
 
@@ -245,4 +245,3 @@ See [Anatomy](/variable-contract/adapters/contract/anatomy) for details.
 - Tokens Studio plugin configuration
 - Tokens Studio sync workflows
 - Conflict resolution between Tokens Studio and version control
-

docs/adoption/getting-started.md

@@ -251,8 +251,8 @@ Avoid these mistakes:
 
 After adoption:
 
-- Review [Implementation Checklist](/variable-contract/adoption/adoption/implementation-checklist)
-- Set up [Migration Strategy](/variable-contract/adoption/adoption/migration-strategy) if migrating
+- Review [Implementation Checklist](/variables-contract/adoption/adoption/implementation-checklist)
+- Set up [Migration Strategy](/variables-contract/adoption/adoption/migration-strategy) if migrating
 - Document team-specific patterns
 - Iterate on workflow
 

docs/contract/anatomy.md

@@ -77,4 +77,4 @@ If anatomy rules are ignored:
 
 - Specific variable values (anatomy governs structure, not content)
 - Number of variables per category (depends on design system size)
-- Naming within categories (see [Naming Convention](/variable-contract/contract/naming))
+- Naming within categories (see [Naming Convention](/variables-contract/contract/naming))

docs/contract/dtcg-alignment.md

@@ -25,10 +25,10 @@ DTCG 2025.10 defines:
 
 Variable Contract adds a governance layer on top of DTCG format:
 
-- Naming convention rules (see [Naming](/variable-contract/contract/naming))
-- Change control process (see [Change Control](/variable-contract/governance/change-control))
-- Role definitions (see [Design Engineer](/variable-contract/governance/roles/design-engineer))
-- Adapter patterns for tool integration (see [Adapters](/variable-contract/adapters))
+- Naming convention rules (see [Naming](/variables-contract/contract/naming))
+- Change control process (see [Change Control](/variables-contract/governance/change-control))
+- Role definitions (see [Design Engineer](/variables-contract/governance/roles/design-engineer))
+- Adapter patterns for tool integration (see [Adapters](/variables-contract/adapters))
 - Validation requirements beyond format correctness
 
 ## Compatibility matrix

docs/contract/types.md

@@ -257,7 +257,7 @@ Examples:
 
 ## Composite types
 
-Composite types combine multiple primitive types into structured values. See [Composite Types](/variable-contract/contract/composite-types) for details.
+Composite types combine multiple primitive types into structured values. See [Composite Types](/variables-contract/contract/composite-types) for details.
 
 Supported composite types: