Packages and compatibility

Available packages

Package	Version	Purpose
portal-kit	0.2.1-migration.0	Game runtime, browser bundle and input/audio/UI/graphics modules
@fah/protocol	0.1.0-migration.0	Message metadata, lifecycle model and manifest validation
@fah/conformance	0.1.0-migration.0	Lifecycle checks and portable fixtures

These are preview packages distributed through source builds and local tarballs. Repository access is required; public npm installation is not available. They remain marked private/UNLICENSED while the SDK license grant is confirmed. Preserve the included notices and attribution; package availability is not a license grant.

Install local tarballs

From a complete SDK checkout, such as the Getting started snapshot:

npm ci --ignore-scripts
npm run pack:packages

Find the tarballs and integrity metadata in artifacts/packages/. In your consuming project, install all three from their absolute paths (replace /absolute/path/to/fah-sdk with your checkout):

npm install --ignore-scripts \
  /absolute/path/to/fah-sdk/artifacts/packages/fah-protocol-0.1.0-migration.0.tgz \
  /absolute/path/to/fah-sdk/artifacts/packages/portal-kit-0.2.1-migration.0.tgz \
  /absolute/path/to/fah-sdk/artifacts/packages/fah-conformance-0.1.0-migration.0.tgz

The SDK source entry requires the exact protocol package version, so install those two tarballs together. Conformance is optional for runtime-only consumers. The standalone browser bundle contains its dependencies and can also be copied from portal-kit/dist/portal-kit.js; Three.js is supplied separately by your game. For the documented 3D examples, install three@0.180.0 in the consuming project. Canvas 2D games do not need it.

Use the package root with a bundler that resolves ES modules and bare package imports. If you serve files directly without a bundler, copy the standalone bundle and use the relative import map. Do not serve the package's source entry as though it were a self-contained browser bundle. Supported entry points and factories are indexed in SDK API.

Keep the producing commit, manifest.json integrity values and your lockfile with the integration. A preview version string alone does not uniquely identify a source build. Use a new commit and integrity pin when consuming a different build. Published package versions must never be replaced with different bytes.

Independent version numbers

Dimension	Current value	Meaning
npm package version	See package table	Package release and dependency resolution
Runtime KIT_VERSION	0.2.1	SDK compatibility stamp in hello messages and game manifests
Wire pp and init v	2	Host/game message protocol
game.json.manifest	2	Manifest format
Contract reference revision	2.6	Revision exposed by CONTRACT_DOCUMENT_VERSION

Do not derive wire or manifest versions from a package's major version. Do not copy the npm prerelease suffix into a game's kit field. Runtime compatibility and package distribution have separate version identities.

Package API changes follow SemVer. Before 1.0, a breaking API change requires a minor version bump and a compatibility note. A breaking wire or manifest change requires an explicit format revision and matching fixtures and host support. Diagnostic codes and warning/error levels are also part of the supported tooling surface. Editorial changes that do not change the contract do not advertise a new wire, manifest or runtime version.