RC support and stability

The documentation targets 1.0.0-rc.1, an npm release candidate. This is not a claim that stable 1.0 has shipped or that every exported feature is certified. Pin the exact RC for evaluation; next is a moving prerelease channel and latest selects the non-prerelease channel.

The support policy owns the current support matrix. Consult the generated export inventory for per-symbol labels and value/type availability.

Stable-candidate is not the same as stable support. Existing deprecated APIs remain deprecated. Experimental surfaces can change; pin dependencies and review changes before upgrading.

Boundaries consumers must retain

• Tenant routing is not authorization. Authenticate first and isolate requests.
• Shared rate-limit stores need atomic increments, not a read/write approximation.
• Do not share cached private, credentialed, cookie-setting or varied responses.
• Workspace filesystem checks are not an OS security boundary for arbitrary commands.
• AI/template output needs review; generation can contain placeholders.
• Static generation is distinct from the unfinished internal unified builder.
• A source module or type-only export does not establish a public runtime API.

Support and reporting

The project has a sole maintainer handling ownership, support and security. There is no implied round-the-clock support team or response-time guarantee. Follow the canonical support policy and security reporting policy. Do not post credentials or private vulnerability details in public issues.

The API review contract describes contributor checks; release records do not create additional consumer guarantees. The public API index identifies available imports.