> ## Documentation Index
> Fetch the complete documentation index at: https://docs.musterbox.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Production checklist

> Everything to verify before you ship a MusterBox-connected game.

Work through this list before moving to production traffic.

## Game setup

* [ ] Game is **published** in the MusterBox console (unpublished games refuse
  to issue SDK sessions with a `403`).
* [ ] A game key exists with the `session` scope and the correct
  `allowedOrigins` for every environment you use.
* [ ] You intentionally selected the right environment per base URL — sandbox
  and production credentials are not interchangeable.

## Session and match flow

* [ ] Every player gets their own session from
  `POST /api/v1/game-sdk/{gameId}/sessions` — never share a session token.
* [ ] The session token is treated as single-use and never persisted.
* [ ] `matchId` is taken from the real match context, never hard-coded.
* [ ] Result outcomes are one of `PLAYER_A_WIN`, `PLAYER_B_WIN`, `DRAW`, and
  only the player's actual claim is sent.
* [ ] Your UI communicates `pending` vs. the final reconciliation decision.

## Authentication

* [ ] Tokens are handled **only** by the SDK; your code never inspects or
  verifies JWT signatures.
* [ ] On `SessionNotAuthenticated` you re-authenticate or surface an error —
  never fall back to unauthenticated privileged calls.
* [ ] `logout` is always attempted on session end so the server revokes the
  session.

## Purchases (if used)

* [ ] Purchases are driven exclusively through the SDK's `PurchaseClient`.
* [ ] You never hand-roll a purchase request.
* [ ] `VerifyRequest` carries a unique `idempotencyKey` per authorized
  withdrawal.
* [ ] The verify call is **never retried** (single-shot session consumption).

## Security posture for web builds

* [ ] The `gameKey` stays in a browser-safe, org-scoped location — it is
  origin-locked, never embedded in mobile binaries.
* [ ] You treat the browser as untrusted and rely on the backend for every
  decision that matters.
* [ ] You do not log tokens, PINs, or wallet material anywhere client-side.

## Observability

* [ ] SDK diagnostics are captured on failure (`getDiagnostics` and native
  `capture_diagnostics` equivalents).
* [ ] `EnvironmentError`, transport, and protocol errors are mapped to
  [SDK error codes](/sdk/errors) for monitoring.

## Before releasing packages publicly

The SDK team currently distributes engine packages as local tarballs
(`dist/`). npm (`@musterbox/sdk-js`, `@musterbox/sdk-wasm`) and crates.io
publication are **not yet live**. Until they are:

* [ ] Vendored builds pin the exact package version (1.0.0) and ABI (1.2.0).
* [ ] Native plugins are built from a tagged SDK source revision.

## Gate

When every item above is checked, you are ready for a sandbox → staging →
production promotion following the [SDK versioning guidance](/guides/migrate-sdk-versions).