# KitJS support policy

KitJS support follows exact release evidence. A browser-family name, mutable
npm dist-tag, or version in a source checkout is not by itself a support claim.

The runtime source and generated artifacts in the current checkout identify
the stable `1.0.0` line. The newest independently verified stable `1.x` patch
is the production support target. `1.0.0-rc.2`, `1.0.0-rc.1`, and
`0.9.0-next.15` are retained only as immutable historical release and
migration evidence.

## Release lines

- During `0.9` prereleases, only the newest exact published prerelease is an
  active upgrade target. Older prereleases remain immutable historical
  evidence and do not receive backports.
- During the `1.0.0-rc.*` cycle, fixes move forward into a new RC. An older RC
  is not patched in place. A local RC becomes an upgrade target only after its
  exact public package and CDN artifacts are independently verified.
- Beginning with `1.0.0` on npm `latest`, the newest patch of the current
  stable `1.x` line is the supported production target. The `0.x` line and
  superseded RCs no longer receive fixes.

Security fixes may require an immediate exact-version upgrade. This repository
does not promise a support duration for an older minor line until a separate
long-term-support policy is published.

## Browser evidence

Release evidence names the exact Kit and Hydrate bytes and browser engines used
by the required CI matrix. For `1.0.0-rc.2`, the tagged CI run passed the
complete package corpus in Chromium and the shared critical matrix in Chromium,
Firefox, and WebKit. A WebKit test is not an unqualified claim about every
Safari release.

KitJS targets modern evergreen engines with the platform primitives exercised
by the package gate, including `Proxy`, `Promise`, `Map`, `Set`, `WeakMap`,
`MutationObserver`, `URL`, `DOMParser`, and delegated DOM events. Hydrate also
requires `fetch`, History, and Abort APIs. KitJS does not ship polyfills.

When an exact browser/version pair is not represented by release evidence,
treat it as unverified and run the package's production-shaped static example
against that target before deployment.

## Profile support

- `dist/kit.js` owns reactive HTML while navigation remains browser-native.
- `dist/hydrate.kit.js` includes the same runtime and attempts Drive/Morph only
  when the current and destination documents satisfy its complete
  compatibility contract.

Hydrate fallback to ordinary navigation is supported behavior, not necessarily
a defect. Reports about an unexpected reload should include the executable
script topology, response headers, final redirected URL, and the terminal
`kit:navigation` outcome.

## Component migration boundary

The standalone 1.0 package has one component authoring form:

- `data-kit-component="name"` for a trusted definition registered through
  `kit.component(name, plainObject)`.

The split `data-kit-version` attribute is rejected by 1.0. The verified public
`0.9.0-next.15` artifact accepts it as deprecated 0.9 compatibility input.
There is no `data-kit-local`; an unversioned component host already expresses
the complete standalone lane. A missing definition is reported and the
authored fallback DOM remains available; the package does not fetch component
code from the component attribute.

## Publication evidence

Release builds generate deterministic `dist/integrity.json` metadata for the
two profile bytes. After an exact release is published, the bounded
`scripts/verify-public-release.mjs` gate compares npm metadata/`gitHead`, the
registry tarball and packaged files, and exact jsDelivr and unpkg artifacts.
For stable releases it additionally verifies npm `latest` and the default
unversioned jsDelivr/unpkg entry points. Signatures, provenance presentation,
and browser/version results remain separate required evidence. Exact run links
and artifact identities are recorded in `RELEASE_READINESS.md` and the
corresponding GitHub release.

Prereleases use the npm `next` channel. A plain stable version publishes
directly to npm `latest`; its workflow must then prove both immutable
exact-version artifacts and the mutable latest/default-CDN resolution. An
unversioned CDN URL is convenient for automatic upgrades, but an exact version
with SRI remains the supported production recommendation.

## Reporting

Use the public issue tracker for reproducible non-sensitive defects. Report a
suspected vulnerability only through the private process in `SECURITY.md`.
Include the exact package version, profile, browser/version, smallest HTML
reproduction, expected outcome, and observed outcome.