Support policy

Supported environment

• Go 1.26.5 on Windows, Linux, and macOS.
• The Spice core minimum and current versions declared in spice-compatibility.json.
• Standard module and vendored, offline builds.
• Release-parity rendering through github.com/spice-framework/development/cmd/spice-dev at v0.0.0-20260806132124-4c308d1b9fda, with independent release verification authorized through github.com/spice-framework/toolchain/cmd/spice-library-release-verify at v0.0.0-20260806133530-71211498297c.

Compatibility policy

Before 1.0, public APIs may change between minor versions. Patch releases do not intentionally break source compatibility. Every release tests the oldest supported Spice core boundary and a reviewed current boundary. Raising the minimum requires a documented release note and a compatibility manifest update.

Security reports

Report vulnerabilities through GitHub private vulnerability reporting. Do not open a public issue containing credentials, tokens, provider responses, or exploit details. General defects and feature requests may use GitHub Issues.

Operational ownership

Applications own credential sourcing, transport TLS roots, timeouts, redirect policy, retry policy, observability, and shutdown context. This starter owns client-credentials acquisition, token caching, protocol validation, safe errors, and HTTPS enforcement. It intentionally performs no automatic discovery or background network activity.

Release artifacts are produced only from an exact tagged commit under the contract in releasing.md. A compromised or missing signing secret fails a production release; it never falls back to unsigned output. The pinned central signer and independent verifier power the protected reusable production workflow. The reviewed repository-specific trust anchor is security/release/ed25519-public.pem (SHA-256 fingerprint c1ff629a8f503bd90d21fd0e6aec5e072f21ceedda9203d8ad01d755d9f66a54). Its private key exists only as repository Actions secret SPICE_LIBRARY_RELEASE_SIGNING_KEY, and the caller explicitly maps only that secret to the protected reusable workflow. Windows and Linux CI render the same inert central plan twice under vendor-only offline resolution and require byte-identical unsigned artifacts.