# Support Policy

## Product versions

Before Zynor 1.0, only the latest published minor line and its latest patch are
supported. A new `0.x` minor may contain intentional compatibility changes;
patch releases must preserve the documented public API and provider names.
Deprecations are documented in `CHANGELOG.md` before removal whenever a
security emergency does not require immediate action.

## Runtime policy

Support means the runtime is represented by a required CI or release gate,
not merely that it can parse the bundle.

| Runtime profile | Support rule |
| --- | --- |
| Node.js | Maintained Node release lines satisfying `engines.node`; test the documented minimum plus current LTS lines |
| Bun | The pinned CI baseline and newer compatible releases; regressions are assessed against the newest stable Bun |
| Deno | The pinned CI baseline and newer compatible releases, with documented npm/Node-API permissions |
| Cloudflare Workers | The pinned Wrangler/workerd compatibility date and later compatible dates; `zynor/native` is unsupported |
| Browser pages/workers | Pinned Playwright Chromium, Firefox, and WebKit projects with the required Web APIs; three-provider DNS and browser-safe email profile with memory-only caches |

An odd-numbered or otherwise end-of-life Node release may happen to work but is
not supported. Consumers must run a current security patch of a maintained
major. The authoritative Node lifecycle is the upstream Node.js release
schedule.

The unreleased browser profile remains release-gated until the checked-in live
origin matrix passes in Chromium, Firefox, and WebKit on hosted runners. Bundle
analysis, deterministic route fixtures, and Node-hosted web-global tests are
useful but are not live-browser provider evidence.

## Native addon policy

`zynor/native` is supported only for target triples whose exact binary is
listed in the release's native-artifact manifest and exercised in release CI.
The current development package stages only `darwin-arm64`; no other native
target should be inferred. The ordinary `zynor` entry remains available on
server runtimes without loading that addon.

## Compatibility promises

- Existing provider `name` values and public method signatures are frozen.
- Backend selection remains entry-point-only.
- Runtime capabilities may differ only where documented in the runtime matrix.
- Error names/messages retained for compatibility are not a substitute for
  stable structured codes; additions must be backward-compatible.
- Provider-data corrections may change classification results when evidence
  shows the previous result was wrong. Such changes require fixtures and a
  changelog entry.

## Getting support

Use the repository issue tracker for reproducible defects and feature
proposals when it is available. Include the Zynor version, runtime version,
entry point, provider configuration, a minimal synthetic example, and the
actual error code/shape. Do not include real email addresses, DNS credentials,
API keys, cache contents, or native binaries from private systems.

Security issues follow [SECURITY.md](SECURITY.md), not the public issue path.