docs: update documentation links and improve navigation

- Renamed "Variable Contract" to "Variables Contract" for consistency across documentation.
- Updated internal links to use relative paths instead of absolute paths for better portability.
- Enhanced navigation by correcting links in various sections, including adapters, governance, and contract documentation.
- Added new HTML files for site structure, including adapters, adoption, and governance sections, improving overall accessibility and organization.

Author: marklearst

docs/adapters/figma.md

@@ -212,7 +212,7 @@ After:
 
 ### Step 6: Validate naming
 
-Check that normalized names follow Variable Contract naming convention (see [Naming](/variables-contract/adapters/contract/naming)).
+Check that normalized names follow Variable Contract naming convention (see [Naming](../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](/variables-contract/adapters/governance/change-control)).
+5. Reviewers check naming, types, references (see [Change Control](../governance/change-control)).
 6. After merge, CI generates build outputs.
 
 ### What gets reviewed
 
-- Variable names follow naming convention ([Naming](/variables-contract/adapters/contract/naming))
+- Variable names follow naming convention ([Naming](../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](/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
+- [Figma Adapter](figma) - Figma Variables export normalization
+- [Tokens Studio Adapter](tokens-studio) - Tokens Studio export normalization
+- [Style Dictionary Adapter](style-dictionary) - Variable Contract to CSS/TypeScript/etc.
+- [Tailwind Adapter](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](/variables-contract/adapters/contract/naming)).
+Check that names follow Variable Contract naming convention (see [Naming](../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](/variables-contract/adapters/governance/change-control)).
+5. Reviewers check naming, types, references (see [Change Control](../governance/change-control)).
 6. After merge, CI validates JSON and generates build outputs.
 
 ### What gets reviewed
 
-- Variable names follow naming convention ([Naming](/variables-contract/adapters/contract/naming))
+- Variable names follow naming convention ([Naming](../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](/variables-contract/adapters/contract/anatomy) for details.
+See [Anatomy](../contract/anatomy) for details.
 
 ### Artifacts that change
 

docs/adoption/getting-started.md

@@ -251,8 +251,8 @@ Avoid these mistakes:
 
 After adoption:
 
-- Review [Implementation Checklist](/variables-contract/adoption/adoption/implementation-checklist)
-- Set up [Migration Strategy](/variables-contract/adoption/adoption/migration-strategy) if migrating
+- Review [Implementation Checklist](adoption/implementation-checklist)
+- Set up [Migration Strategy](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](/variables-contract/contract/naming))
+- Naming within categories (see [Naming Convention](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](/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))
+- Naming convention rules (see [Naming](naming))
+- Change control process (see [Change Control](../governance/change-control))
+- Role definitions (see [Design Engineer](../governance/roles/design-engineer))
+- Adapter patterns for tool integration (see [Adapters](../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](/variables-contract/contract/composite-types) for details.
+Composite types combine multiple primitive types into structured values. See [Composite Types](composite-types) for details.
 
 Supported composite types:
 

docs/contract/variable-contract.md

@@ -10,15 +10,15 @@ If the contract is loose, you get silent renames, broken references, and "same v
 
 ## DTCG compliance
 
-This contract is DTCG 2025.10 compliant. See [DTCG Alignment](/variables-contract/contract/dtcg-alignment) for details.
+This contract is DTCG 2025.10 compliant. See [DTCG Alignment](dtcg-alignment) for details.
 
 ## Inputs and adapters
 
 This contract defines the canonical shape used in version control.
 
 Tool exports (example: a Figma variable export JSON) are treated as inputs. They may include extra metadata and alternate reference syntax. An adapter can normalize those inputs into this contract.
 
-See [Adapters](/variables-contract/adapters) for adapter patterns and implementations.
+See [Adapters](../adapters) for adapter patterns and implementations.
 
 ## Adapter pipeline
 
@@ -40,7 +40,7 @@ A variable is an object with the following properties:
 
 A group is an object that contains nested groups and/or variables. Groups do not have `$type`/`$value`.
 
-Groups can extend other groups using `$ref`. See [Groups](/variables-contract/contract/groups) for details.
+Groups can extend other groups using `$ref`. See [Groups](groups) for details.
 
 ## `$type`
 
@@ -52,7 +52,7 @@ Rules:
 - A variable's `$type` must not change unless it is a breaking change.
 - Composite types must use the expected structure for that type.
 
-See [Types](/variables-contract/contract/types) for the complete type reference and [Composite Types](/variables-contract/contract/composite-types) for structured types.
+See [Types](types) for the complete type reference and [Composite Types](composite-types) for structured types.
 
 ## `$value`
 
@@ -75,7 +75,7 @@ Rules:
 - Mode names should not change without a breaking change.
 - A mode value may be a literal value or a reference.
 
-See [Modes](/variables-contract/contract/modes) for complete mode documentation including structure, resolution, and consistency rules.
+See [Modes](modes) for complete mode documentation including structure, resolution, and consistency rules.
 
 ## References (aliases)
 
@@ -101,7 +101,7 @@ Rules:
 - JSON Pointer syntax is supported for DTCG compliance.
 - Tool-specific reference formats are allowed only as adapter inputs.
 
-See [References](/variables-contract/contract/references) for complete reference documentation including resolution algorithms, chained references, and property-level references.
+See [References](references) for complete reference documentation including resolution algorithms, chained references, and property-level references.
 
 ## `$description`
 
@@ -137,15 +137,15 @@ Rules:
 
 A change is considered valid if:
 
-- Names follow the naming convention ([Naming](/variables-contract/contract/naming)).
+- Names follow the naming convention ([Naming](naming)).
 - Every variable has `$type` and `$value`.
-- References resolve and are acyclic (see [References](/variables-contract/contract/references)).
+- References resolve and are acyclic (see [References](references)).
 - References use the canonical reference syntax (`{path}`).
 - If `$value` uses modes, mode keys are explicit and shared within a collection.
 - Alias variables do not duplicate raw palette values when a base variable exists.
 - Component variables do not reference base variables directly unless explicitly documented.
 - Breaking changes are versioned and documented (rename, removal, `$type` change).
-- Group extensions (`$ref`) do not create circular references (see [Groups](/variables-contract/contract/groups)).
+- Group extensions (`$ref`) do not create circular references (see [Groups](groups)).
 
 ## Conformance
 
@@ -157,7 +157,7 @@ Variable Contract conformance requires:
 - Validation implementation
 - Versioning compliance
 
-See [Conformance](/variables-contract/reference/conformance) for complete conformance requirements and how to claim compliance.
+See [Conformance](../reference/conformance) for complete conformance requirements and how to claim compliance.
 
 ## Out of scope
 

docs/examples/adapter-pipeline.md

@@ -57,7 +57,7 @@ Figma Variables export JSON:
 
 ## Step 2: Figma adapter normalization
 
-After running the Figma adapter (see [Figma Adapter](/variables-contract/examples/adapters/figma)):
+After running the Figma adapter (see [Figma Adapter](adapters/figma)):
 
 ```json
 {

docs/examples/figma-export.md

@@ -8,7 +8,7 @@ This is an example input file shape from a Figma Variables export.
 
 - Raw file: `figma-export.json`
 
-This export format includes Figma-specific metadata and reference syntax. Use the [Figma Adapter](/variables-contract/adapters/figma) to normalize it into the canonical contract format defined in [Variable Contract](/variables-contract/contract/variable-contract).
+This export format includes Figma-specific metadata and reference syntax. Use the [Figma Adapter](../../adapters/figma) to normalize it into the canonical contract format defined in [Variable Contract](../../contract/variable-contract).
 
 ## Normalization required
 
@@ -20,4 +20,4 @@ Figma exports need normalization before use:
 4. Convert reference syntax (`{@collection.token}` → `{collection.token}`)
 5. Move mode values from metadata to `$value` objects
 
-See [Figma Adapter](/variables-contract/examples/adapters/figma) for complete normalization steps.
+See [Figma Adapter](../adapters/figma) for complete normalization steps.