@indiegems/gem-web-sdk 9.1.3 → 10.0.0

package/docs/changelog.md

@@ -16,6 +16,25 @@ Its entries are grouped under up to five headings:
 - **Rebuild**: a type changed. Recompile against the new version; code that compiles today keeps compiling unless the entry says otherwise.
 - **New capability**: something a game can now do. Nothing changes unless you use it.
 
+## 10.0.0
+
+Upgrading from 9.1.4. Impact: required.
+
+### Rebuild
+
+- The OrderSource type now accepts two more values, test_account_provision and developer_grant. Recompile your game. If your code handles order sources in an exhaustive switch or a lookup table typed by OrderSource, add handling for both new values, or the build may fail to compile.
+
+### New capability
+
+- A game can now put a player in a matchmaking queue for a mode that needs a formed lobby. Call RoomManager.queueForMatch with the template slugs you want. It returns a MatchTicket whose outcome settles once and whose cancel method leaves the queue. When the platform finds a match it creates the room, seats everyone and starts the match, and you follow it with the same code you use for any joined room. Options are described by QueueForMatchOptions. Ticket endings are described by MatchTicketOutcome, and the waiting state by MatchTicketStatus. RoomManager.currentTicket exposes the ticket the player is waiting on. The SDK keeps the ticket alive by itself, cancels it when the tab closes, and lets a player queue from inside a room. After a match the player leaves the room they queued from when the tab closes.
+- The lower-level rooms API now has createTicket, heartbeatTicket and cancelTicket calls for working with matchmaking tickets directly. Most games should use RoomManager.queueForMatch, which sends the heartbeats and cancellation for you.
+
+## 9.1.4
+
+Upgrading from 9.1.3. Impact: none.
+
+Nothing in this release asks anything of a game.
+
 ## 9.1.3
 
 Upgrading from 9.1.2. Impact: none.

package/docs/daily-challenges.md

@@ -78,9 +78,118 @@ Changing only these two is not a change of schedule, so the upload does not refu
 `completion_threshold` is the target. `client_writable` decides who may report it, and
 [section 4](#4-who-may-report-it) is where that choice actually matters.
 
+`display_name` and `description` are what a player reads. To translate them, or to have the
+platform write the target into them, see
+[section 2a](#2a-translate-the-copy-and-write-the-target-into-it).
+
 **Upload the config the way you upload any other.** A challenge is not promoted differently and
 does not need a new build to reach players.
 
+## 2a. Translate the copy, and write the target into it
+
+Both of these are optional, and a config that uses neither keeps working as it is. A progression
+may carry your own translations of its name and description, and a displayed challenge may have the
+platform write its target into the text:
+
+```yaml
+progressions:
+  - id: 9b1d6e40-52c7-4f0a-8e3d-1a7c4b9f2d65
+    slug: clear-lines
+    display_name: 'Clear {target, plural, one {# line} other {# lines}}'
+    description: 'Clear lines in a single run.'
+    localized:
+      de:
+        display_name: 'Räume {target, plural, one {# Reihe} other {# Reihen}} ab'
+        description: 'Räume Reihen in einem Durchgang ab.'
+      pl:
+        description: 'Usuń linie w jednej rozgrywce.'
+    config:
+      completion_threshold: 150
+      reset_schedule: { type: daily }
+      platform_display: challenge
+```
+
+Quote the text. YAML reads an unquoted value that starts with `{` as a mapping, so
+`display_name: {target} points` is not a string.
+
+### Translations
+
+Any progression may carry `localized`, whether or not it is a displayed challenge.
+
+- **The keys are the eleven locales:** `de`, `es`, `fr`, `it`, `ja`, `ko`, `pl`, `pt-BR`, `ru`,
+  `tr`, `zh-Hans`. `en` is refused as a key, and so is any other key.
+- **Each entry has two optional fields**, `display_name` and `description`. You may translate one
+  and not the other.
+- **The `display_name` and `description` you write outside `localized` are the default text**, and
+  the platform treats them as English. A missing locale, or a missing field in a locale, falls back
+  to the default text, one field at a time. In the example, a Polish reader gets the default name
+  and the Polish description, and a French reader gets the default text for both.
+- **An empty translation is refused.** To show the default text, remove the key.
+- **Translations are optional**, and promoting a config does not depend on them.
+
+### Write the target with {target}
+
+On a displayed challenge (`platform_display: challenge`), `{target}` in `display_name` or
+`description` is replaced by the challenge's `completion_threshold`. It works in the default text
+and in every translation. Copy that already contains the literal text `{target}` is now shown with
+the number in its place.
+
+| You write                                              | Target | A player reads        |
+| ------------------------------------------------------ | ------ | --------------------- |
+| `Score {target} points`                                | 12000  | Score 12,000 points   |
+| `Erziele {target} Punkte`, under `de`                  | 12000  | Erziele 12.000 Punkte |
+| `Clear {target, plural, one {# line} other {# lines}}` | 1      | Clear 1 line          |
+| the same                                               | 150    | Clear 150 lines       |
+
+- **`target` is the only name.** Any other `{name}` is refused, and so is `{target}` on a
+  progression with no `completion_threshold`.
+- **The number is grouped the way the reader's language groups it:** `12,000` in English, `12.000`
+  in German. Each text uses one language for its words, its plural rule and its number.
+- **A plural needs an `other` branch.** `Clear {target, plural, one {# line} other {# lines}}` is
+  "Clear 1 line" at 1 and "Clear 150 lines" at 150.
+- **Write category branches (`one`, `few`, `many`, `other`), not `=N`.** An exact branch is
+  accepted only when `N` equals the current threshold, so if you later change the threshold, copy
+  that used `=N` can fail its next upload. Each text uses the categories its own language has: a
+  category that no number takes in that language (`few` in English) is refused, and so is a branch
+  written twice.
+- **Each player reads the target they are working toward.** A player who started a period before
+  you changed the threshold keeps reading their own number, in the copy and on the meter alike.
+  Section 8 has what a change of threshold does to a period in progress.
+
+### The rules for a displayed challenge's copy
+
+- **On a displayed challenge the name and description are templates, and `{` and `}` are syntax.**
+  On any other progression they are plain text, and braces mean nothing.
+- **The name is at most 64 characters and the description at most 280, counted
+  on the line a player is shown**, in every language, never on the template. Nothing is truncated;
+  text that renders too long is refused. A long plural is therefore fine when each line it renders
+  is short. The text as written may be up to 256 characters for a name and 4096 for a description.
+- **A displayed challenge's name and description are each one line.**
+- **The copy is screened at upload, in every language.** It is refused for words that claim to
+  speak for the platform or name a platform role, for the name of a platform currency, for reward
+  or credential words, and for links.
+- **Some problems are refused today, and some only draw a warning.** A problem in a `localized`
+  entry, or in text that uses `{target}`, is refused. A problem in a displayed challenge's default
+  text that does not use `{target}` (a stray brace, a line break, a screened word) draws the
+  warning `progressions_copy_refusal_pending` with the same message, and the upload succeeds. That
+  warning will become a refusal, so fix the text when you see it. It follows the text, not its age:
+  default text without `{target}` on a challenge you add today draws the same warning.
+- **A translation on a progression that is not a displayed challenge is plain text**, held to 64 /
+  280 characters as written. It is still refused for a link or for words that claim to speak for
+  the platform, and its description may have line breaks.
+
+### What a player reads, and what your game reads
+
+- **Where the platform shows a progression's name and description, a reader gets your translation
+  when there is one for their language, and the default text otherwise.**
+- **Your game's own reads do not return this text.** `gem.challenges.list()` and the progression
+  read (`currentValue`, `isCompleted`) carry no name and no description.
+- **`gem.gameConfig.load()` returns the config as you wrote it:** `display_name` and `description`
+  with `{target}` still in them, not replaced, and not chosen for the player's language. It also
+  returns your `localized` entries as written.
+- **A game that shows its own challenge UI keeps rendering its own strings**, in
+  `gem.prefs.locale`.
+
 ## 3. Report progress from your game
 
 The write is the ordinary progression write. Your game already knows how to make it:
@@ -506,7 +615,9 @@ shows, just quietly meaningless.
 
 - **A new challenge gets a new id.** Always.
 - **To rename what the player sees, change `display_name`.** That is free and is not part of the
-  challenge's identity.
+  challenge's identity. Update that name's translations in `localized` too
+  ([section 2a](#2a-translate-the-copy-and-write-the-target-into-it)): a translation you leave
+  behind keeps showing the old name to readers of that language.
 - **Changing a progression's `reset_schedule` is refused at upload**, for the same reason: a daily
   that becomes a weekly would carry its old id into a history that then describes two different
   things. A different period means a new progression. (Rewriting `0 0 * * *` as `daily` is not a
@@ -590,6 +701,17 @@ own streak on your store page. Your game does not have to render any of it.
 | `cron expression never fires`                      | an expression naming a date that does not exist (`0 0 30 2 *`)  | fix the expression                                                   |
 | `reset_schedule changed from … to …`               | you changed a live progression's period                         | use a NEW progression; `display_name` is what renames one            |
 | warning `platform_grant_max_per_window_ignored` (or `platform_grant_cap_uses_retired_max_per_entity`) | a mapping declares `max_per_window` (or `max_per_entity`) | nothing is refused and the upload succeeds; remove the key, because the platform sets the caps |
+| a refusal at `localized.<key>`                     | the key is not one of the eleven locales, or it is `en`         | use a listed locale; the text outside `localized` is the English    |
+| a refusal at a `localized.<locale>` field that is empty | an empty translation                                       | remove the key to show the default text                             |
+| a refusal naming a `{name}` other than `target`    | a displayed challenge's copy referred to something else         | `target` is the only name; remove the braces from the copy          |
+| a refusal for `{target}` with no threshold         | the progression has no `completion_threshold`                   | set one, or remove `{target}`                                       |
+| a refusal on a plural branch                       | no `other` branch, an `=N` that is not the threshold, or a category the language does not have | write the category branches that language has, and always `other` |
+| a refusal for text that is too long                | the line a player is shown passes 64 (name) or 280 (description) | shorten the text; nothing is truncated for you                     |
+| warning `progressions_copy_refusal_pending`        | default text without `{target}` on a displayed challenge breaks a copy rule | the upload succeeds; fix the text now, because this will become a refusal |
+
+A refusal about a progression's copy reads `progressions[<i>] (<slug>): <path>: <reason>`, where
+`<path>` is `display_name`, `description`, `localized.<locale>.display_name`,
+`localized.<locale>.description`, or `localized.<key>` for a refused key.
 
 Every refusal names the field and the reason. **Read the error rather than a list written down
 here** — the platform is what decides these, and this table is only as current as the day it was

package/docs/getting-started.md

@@ -50,7 +50,7 @@ either way.
 ```jsonc
 // package.json
 "dependencies": {
-  "@indiegems/gem-web-sdk": "9.1.3"
+  "@indiegems/gem-web-sdk": "10.0.0"
 }
 ```
 
@@ -248,12 +248,12 @@ Once it is open:
 - **Fullscreen covers it.** Leave fullscreen to see it again.
 
 The panel is also reachable from inside your game — see
-[GemDevTools.open](https://gemarcade.com/developer/api/game#gemdevtools-open), which answers
+[GemDevTools.open](api/api-reference-game.md#gemdevtools-open), which answers
 `false` for a session that was not granted it rather than throwing — though it does reject if a
 panel it _is_ allowed to open fails to load, so catch it either way.
 
 If you put your own button on it, gate the button on
-[`onDevToolsPermissionChange`](https://gemarcade.com/developer/api/game#gemoptions-ondevtoolspermissionchange)
+[`onDevToolsPermissionChange`](api/api-reference-game.md#gemoptions-ondevtoolspermissionchange)
 rather than checking anything at boot:
 
 ```js
@@ -559,5 +559,5 @@ credential made for a build pipeline can upload and promote, and cannot delete.
   items, shops or loot. Start with **[the shop tutorial](game-economy-tutorial.md)** to build one.
 - **[Rooms and the match lifecycle](rooms-and-matches.md)** — if it is multiplayer.
 
-The [API reference](https://gemarcade.com/developer/api) has every symbol the SDK publishes,
-with signatures and descriptions.
+The [API reference](api/api-reference-game.md) has every symbol the SDK publishes, with
+signatures and descriptions; the [server half](api/api-reference-server.md) is beside it.

package/docs/manifest.json

@@ -33,8 +33,8 @@
     },
     {
       "file": "changelog.md",
-      "sha256": "785ad9b32a4bf1c37db8583c98d9302456b3fb5d4c6309edc1bf89d6e2f31034",
-      "updated": "2026-10-09T21:32:29Z"
+      "sha256": "cdaa2661a18afd096def083e5a44b2e125275d2aaa210b5d1e496631bf18f457",
+      "updated": "2026-10-10T18:47:07Z"
     },
     {
       "file": "cross-promotion.md",
@@ -43,8 +43,8 @@
     },
     {
       "file": "daily-challenges.md",
-      "sha256": "c198868e2cb1f1b5d9164bb5b1d23bf3f502987e45e10163c8b048a8eba24667",
-      "updated": "2026-10-02T23:01:00Z"
+      "sha256": "f4842b2fe01c8780020326f4722ab69dc01c1f40e1e6455cf2fb27752094383d",
+      "updated": "2026-10-10T14:37:50Z"
     },
     {
       "file": "dedicated-server-flow.md",
@@ -68,8 +68,8 @@
     },
     {
       "file": "getting-started.md",
-      "sha256": "ebfb03fe43f9f5b499cc383881c396132481cf2d4d5fb045bb1bf31f3f37db62",
-      "updated": "2026-10-09T21:32:29Z"
+      "sha256": "39812f4b84097fd29f4038324a9070eeddf526ca294f7cb5b7b3913335ac34bf",
+      "updated": "2026-10-10T18:47:07Z"
     },
     {
       "file": "inventory-and-catalogs.md",
@@ -93,8 +93,8 @@
     },
     {
       "file": "platform-rules.md",
-      "sha256": "76fa088b27d27f7e5c936540a65ed5dc7c9f957334d0db650135173672ffba4d",
-      "updated": "2026-10-09T00:14:06Z"
+      "sha256": "b259bcebc6ae12b1db9c7279a6e2adb174af9d60090bf31001e23616f6423fbf",
+      "updated": "2026-10-10T00:12:33Z"
     },
     {
       "file": "player-sign-in.md",
@@ -113,8 +113,8 @@
     },
     {
       "file": "rooms-and-matches.md",
-      "sha256": "0abf3717a42c94ec832dfa1310c2d93a9f58236fd75b0aacaab301976bffe286",
-      "updated": "2026-10-07T19:27:16Z"
+      "sha256": "23540a20bdd8c8d058eb06d8ef11085ffd8eaaeeaadc93a807608b7c279e240c",
+      "updated": "2026-10-10T18:05:31Z"
     },
     {
       "file": "saving-player-progress.md",
@@ -123,13 +123,13 @@
     },
     {
       "file": "server-bundles.md",
-      "sha256": "b1f6799b8b0abbbaeed801f50c50cd31faff37f91d2671e3aed8150997ca2415",
-      "updated": "2026-10-09T21:32:29Z"
+      "sha256": "43a7674a6da40e2091538d6a24664a66c4cf607cc16b6027f2ddf6fd7421861c",
+      "updated": "2026-10-10T18:47:07Z"
     },
     {
       "file": "serverless-functions-js.md",
-      "sha256": "a8e66db4913654ba0ccca0e97cd40061c3854ce5b8900498d27c06c7fdf6ce2f",
-      "updated": "2026-10-09T20:20:17Z"
+      "sha256": "56588d50d5a59f066164565470663f8f9da03fe85d98a96d3754e6ec14eb9fac",
+      "updated": "2026-10-10T00:12:33Z"
     },
     {
       "file": "serverless-functions.md",

package/docs/platform-rules.md

@@ -295,12 +295,12 @@ them to do something is.
 Both of these are working code in this repository. Neither was linked from anywhere until this page
 existed, which is how integrators end up rebuilding them.
 
-- **[`examples/e2e/`](../examples/e2e/README.md) — the bridge, end to end, in a real browser.** A real
+- **`examples/e2e/` — the bridge, end to end, in a real browser.** A real
   parent page and a real game frame, served from two different origins, exchanging a real
   `MessagePort`. `pnpm e2e` builds the artifacts and serves it. This is the thing to run when a
   handshake is not landing and you need to know whether the problem is the SDK or your page:
   `?sandbox=strict` reproduces the sandbox failure on demand.
-- **[`examples/server-bundle/echo.mjs`](../examples/server-bundle/echo.mjs) — a complete dedicated
+- **`examples/server-bundle/echo.mjs` — a complete dedicated
   server for a match, in one file.** The lifecycle a bundle implements and the first message on the
   channel, running. Its contract is [`server-bundles.md`](server-bundles.md).
 

package/docs/rooms-and-matches.md

@@ -746,16 +746,140 @@ for it would find it, and the room would still be briefly the wrong size — a v
 by a hidden one. The platform refuses the field outright, for this reason: a
 developer meets the rule locally rather than as a 400 in production.
 
+## 5c. Queueing for a match: tickets
+
+`quickJoin()` puts a player in a room at once and lets the room fill around them. That is right for a
+drop-in mode and wrong for one that must not start short — a duel, a team mode — because the first
+player in sits alone in a lobby, and a match is sized by who is there when it starts.
+
+`queueForMatch()` is the other way in. The player waits in a queue; when the platform has enough
+players for one of the templates the ticket named, it makes the room, seats every one of them and
+starts the match. Nobody hosts, and nobody calls `startMatch()`.
+
+```js
+const ticket = await gem.rooms.queueForMatch({ templateSlugs: ['duel', 'brawl'] });
+showSearching({ expiresAt: ticket.expiresAt, onCancel: () => ticket.cancel() });
+
+const outcome = await ticket.outcome;
+if (outcome.status === 'matched') enterMatch(outcome.room);
+else backToMenu(outcome.status);
+```
+
+**A template has to opt in.** A room template is queueable when its `matchmaking` block says
+`enabled: true`; a ticket naming one that does not is refused whole, **400
+`matchmaking_not_enabled`**. `fill_window_seconds` in that block is how long a queue holds out for
+`max_players` before it accepts `min_players`. The block cannot be combined with `auto_start_host`.
+
+**A ticket names every mode the player accepts**, one to eight templates, and is matched under
+whichever fills first. That is one ticket, not several: a player can be on one ticket at a time, across
+every game.
+
+### What the SDK does while the ticket waits
+
+- **It keeps the ticket alive.** A ticket nobody heartbeats is expired by the platform, so that a
+  player who closed the tab does not hold a place in a lobby. The interval is the platform's setting
+  and arrives on the ticket; the SDK reads it from there and a game never sends a heartbeat.
+- **The heartbeat is also how it learns the answer.** Each one returns the ticket as it stands, so a
+  match is noticed within one interval even when nothing crosses the bridge.
+- **A relayed push makes it ask at once.** The match's own start is relayed like any room event (§3),
+  and one that arrives about a room the manager is not in, while a ticket waits, is treated as a cue:
+  the ticket is read immediately, and once more a second later if it still says `queued` — the
+  platform sends the push a moment before it marks the ticket. So on a page that relays, a match is
+  noticed in about the time the push takes, not at the next heartbeat. A tab returning to the
+  foreground is the same cue. Like every relay it is a hint: nothing is entered on its strength.
+- **It refuses a second thing in flight.** While a ticket waits, `create`, `join`, `joinByCode`,
+  `quickJoin` and another `queueForMatch` are refused locally.
+- **It cancels the ticket when the tab closes.** See below.
+- **It raises no `seated` for the ticket's own room.** The owner is told by the outcome. Party
+  members, who hold no ticket, are told by `seated` as they are for any room their leader enters.
+
+### Queueing from inside a room
+
+A player sitting in a hub or a social lobby can queue without leaving it. The ticket takes no seat
+while it waits, and `gem.rooms.currentRoom` stays the room they are in.
+
+When the ticket is matched, **the manager moves and the seat stays**. `currentRoom` becomes the
+match's room and `joined` fires for it. The room the player queued from is not left: no leave is
+sent, no `left` is raised, and the platform still counts them as a member there. When the match is
+over, `gem.rooms.leave()` then `gem.rooms.join(hub.id)` puts them back — `join()` on a room a player
+already holds a seat in answers with the room.
+
+Keep the hub's id if you want that return trip: `currentRoom` is the match's room now, and the
+manager does not hand the old one back.
+
+**A tab closed before the player goes back leaves both rooms.** The SDK remembers the room a matched
+ticket moved it out of, and on `pagehide` sends a keepalive leave for it as well as for the room it
+is in. Otherwise the hub seat would outlive the page with nothing tracking it, and the player's next
+session would start already inside a room. Once the player is back in the hub, it is the tracked
+room again and the ordinary leave covers it.
+
+### When the tab closes
+
+**The ticket is cancelled as the page goes away.** On `pagehide` the SDK sends the cancel as a
+keepalive request, which the browser delivers after the document is gone, and settles the ticket
+`cancelled`. Without it a closed tab's ticket would stay matchable until the platform noticed nobody
+was keeping it alive, and a match formed in that window seats a player who is not there.
+
+This also happens when the page is put in the back/forward cache. A frozen page keeps nothing alive,
+so the player cannot come back to the same ticket; they come back to one that reads `cancelled` and
+queue again.
+
+The platform's own timeout is still there for a tab that crashed or lost its network, where no
+request can be sent. It is the fallback, not the mechanism.
+
+### How a ticket ends
+
+`ticket.outcome` settles once, and **resolves** for every ending the platform reports — these are
+outcomes to branch on, not errors to catch:
+
+| `status` | `reason` | What happened | Queue again? |
+| --- | --- | --- | --- |
+| `matched` | — | Seated, and the match is starting. `gem.rooms.currentRoom` is `outcome.room`, `joined` has fired, and the match events follow as for any room. | — |
+| `expired` | `timed_out` | Nobody to play with before the ticket's expiry. | on a fresh press |
+| `expired` | `heartbeat_lapsed` | The tab was throttled or offline too long to keep it alive. | on a fresh press |
+| `cancelled` | `requested` | `ticket.cancel()`. | — |
+| `cancelled` | `party_changed` | The party gained or lost a member while it waited. | once the party is settled |
+| `failed` | `handoff_failed` | A match formed and could not be started, several times over. | later; this is the platform's fault |
+| `lost` | — | The platform no longer has the ticket. Queues are held in memory and a restart loses them. | yes |
+| `unavailable` | — | Matchmaking is turned off, or stopped answering for longer than a ticket survives. | not in a loop |
+
+`lost` and `unavailable` are the SDK's own conclusions. A heartbeat answered "no such ticket" ends
+the wait as `lost` at once. Three heartbeats in a row that got no usable answer end it too — as
+`unavailable` when the platform said matchmaking is off, `lost` otherwise — and the SDK sends one
+cancel on its way out, in case the requests arrived and only the answers were lost.
+
+It **rejects** in one case: the ticket was matched and the room it was seated in could not be read. The
+seat stands, so `myRooms()` shows the room and `join(id)` enters it.
+
+**`cancel()` can lose the race.** A ticket the platform has already seated is never undone, so
+`cancel()` resolves the ticket's real outcome, and that may be `matched`. Backing out from there is
+`gem.rooms.leave()`.
+
+### The refusals when queueing
+
+`queueForMatch()` itself rejects with `GemApiError` when no ticket was made. Branch on `code`:
+
+| Code | Meaning |
+| --- | --- |
+| `already_queued` (409) | This player, or someone in their party, is already on a ticket — another tab, or another game. |
+| `matchmaking_not_enabled` (400) | A named template has no enabled `matchmaking` block. A config fault, not a player one. |
+| `matchmaking_unavailable` (503) | Matchmaking is turned off for the whole platform, or its store is not answering. |
+
+⚠️ **Nothing falls back to quick-join, and a game should not either.** Not on
+`matchmaking_unavailable`, not on `expired`. Quick-join puts the player in a different kind of room —
+alone, in a mode that was queued for precisely because it needs a lobby. Tell the player matchmaking is
+unavailable and leave the button where it is.
+
 ## 6. Scope
 
 **In:** rooms, membership, host, ready state, the match lifecycle, and the dedicated-server connect
 flow reshaped around them. P2P _allocation_ falls out of the same shape — `startMatch` is one route
 and a P2P match simply reports `ready` at once.
 
-**Out:** matchmaking beyond the engine's find-or-create. `quickJoin()` is exactly `quick_join`: join
-an open public room matching the template, in a cluster this player can play well in, or create one.
-There is no ranked
-system, no skill rating and no queue, and inventing one is not a small addition to this.
+**Out:** matching by anything but arrival order. `quickJoin()` is exactly `quick_join`: join an open
+public room matching the template, in a cluster this player can play well in, or create one.
+`queueForMatch()` (§5c) waits for a full lobby, oldest ticket first. There is no ranked system and no
+skill rating, and inventing one is not a small addition to this.
 
 **Elsewhere:** P2P _connection_ and parties. Both are
 [`p2p-and-parties.md`](p2p-and-parties.md). Three things surface here:

package/docs/server-bundles.md

@@ -80,8 +80,8 @@ To check the download yourself: the package npm serves is, byte for byte, the fi
 also publishes on its download host, with the hash beside it:
 
 ```bash
-curl -fsSL -O https://downloads.gemarcade.com/sdk/v9.1.3/gem-web-sdk.tgz
-curl -fsSL https://downloads.gemarcade.com/sdk/v9.1.3/gem-web-sdk.tgz.sri
+curl -fsSL -O https://downloads.gemarcade.com/sdk/v10.0.0/gem-web-sdk.tgz
+curl -fsSL https://downloads.gemarcade.com/sdk/v10.0.0/gem-web-sdk.tgz.sri
 openssl dgst -sha384 -binary gem-web-sdk.tgz | openssl base64 -A
 ```
 
@@ -261,7 +261,7 @@ other version-skew member on `host`:
 | `leave`   | `cause` — why the connection ended, as the runtime saw it; `superseded` means the same player is already back on a newer connection and the `join` that says so follows at once                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
 | `message` | `reliable` / `ordered` — [the delivery class the sender asked for](#delivery-classes-the-flags-are-the-senders-request); `sessionId`; `playerNumber`                                                                     |
 
-A complete working example is [`examples/server-bundle/echo.mjs`](../examples/server-bundle/echo.mjs)
+A complete working example is `examples/server-bundle/echo.mjs`
 — a chat relay in one file, exercising every lifecycle method, the startup reads and most of the
 runtime surface. This repo's suite drives it against the contract below, so it is a starting point
 rather than a sketch.
@@ -493,7 +493,7 @@ and inherits none of that, which is why the example above loops around it.
 
 A complete, runnable version of this — with the slot's access rules, the room template that makes a
 dedicated server exist at all, and a real match's logs — is
-[`examples/server-saves/`](../examples/server-saves/README.md) in the SDK repository. It refuses the
+`examples/server-saves/` in the SDK repository. It refuses the
 upload outright where the snippet above merely skips an unexpected header, because a grant naming
 something else is a platform bug worth surfacing rather than working around.
 

package/docs/serverless-functions-js.md

@@ -1,6 +1,8 @@
 # Serverless functions in JavaScript
 
-<!-- gem-web: unpublished — the platform does not run JavaScript functions yet -->
+**The platform does not run JavaScript functions yet.** This page describes how one is written
+and how it behaves; today a function you publish is a WebAssembly component, as
+[serverless-functions.md](serverless-functions.md) describes.
 
 A serverless function can be written in JavaScript or TypeScript instead of Rust: the language your
 game is already written in, so the verification code in your browser game moves into a function

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@indiegems/gem-web-sdk",
-  "version": "9.1.3",
+  "version": "10.0.0",
   "description": "postMessage bridge contract between gem-web and browser-playable games",
   "license": "UNLICENSED",
   "type": "module",