# `version` — chassis runtime version constant

## Purpose

Declares the running version of `@suaveplan/react-ui` as the constant
`REACT_UI_VERSION`. The version is hand-maintained to mirror the
`package.json#version` field. The chassis pack-version-check uses this
constant to evaluate every registered pack's `peerRange` against the
running version, so the value MUST track `package.json` exactly.

## Features

- Single export — `REACT_UI_VERSION: string`
- Plain string literal so the bundler does NOT need to read
  `package.json` at runtime (avoids unwanted Node-only bundle surface)
- Imported by the pack registry's version check

## Usage: Basic example

```ts
import { REACT_UI_VERSION } from "@suaveplan/react-ui";

console.log(REACT_UI_VERSION); // "0.1.0"
```

## Usage: Advanced example

```ts
import { REACT_UI_VERSION } from "@suaveplan/react-ui";
import { satisfiesPeerRange } from "@suaveplan/react-ui/pack";

function isCompatible(pack: { peerRange: string }): boolean {
    return satisfiesPeerRange({
        reactUiVersion: REACT_UI_VERSION,
        peerRange: pack.peerRange,
    });
}
```

## API Reference

- `REACT_UI_VERSION: '0.0.0'` — the literal version string

## Implementation notes

The constant is updated by hand whenever the package's `version` field
in `package.json` changes. A future helper script can keep them in
sync automatically; for now the chassis is at `0.1.0` per the
"every package starts at 0.0.0 until graduation" convention so the
hand-maintained constant has not yet drifted. Avoiding a runtime
`package.json` import is deliberate — Vite would either need to inline
the JSON at build time or fall back to a Node `fs` read at runtime,
and the latter would inject Node-only code into a package whose
peerDeps include browser environments. Hand-maintaining the constant
keeps the chassis bundle browser-pure. Consumers wiring an SSR
environment (Next 14+, Remix) can read the constant just like any
other export and are guaranteed the literal string matches the
shipped build artifact. The pack-registry uses this exact value to
decide whether a registered pack's `peerRange` is satisfied so packs
declaring `^0.1.0` resolve to satisfied during the pre-1.0
phase. Once the chassis cuts a 1.0.0 release the constant flips and
every shipped pack's `peerRange` MUST be reviewed in the same wave to
avoid a flood of `pack.version_mismatch` warnings.