castle-web-sdk 0.4.46 → 0.4.48

package/README.md

@@ -26,12 +26,15 @@ import { setup, initCard, Store, Leaderboard } from "castle-web-sdk";
 - [Pass](#pass)
 - [Snapshot](#snapshot)
 - [Portal](#portal)
+- [Social](#social)
+- [Party](#party)
 - [Hub](#hub)
 - [Decks](#decks)
 - [Clipboard](#clipboard)
 - [Haptics](#haptics)
 - [Agent](#agent)
 - [Lifecycle](#lifecycle)
+- [Display](#display)
 - [Multiplayer](#multiplayer)
 - [Setup](#setup)
 - [Saving files](#writefilepath-contents-promisevoid)
@@ -65,6 +68,18 @@ reconnects temporary socket drops automatically. `onStateChange` reports
 `acquiring`, `connecting`, `connected`, `reconnecting`, and `closed`; its optional
 metadata distinguishes a server `bye`, a replaced server version, an explicit
 `leave`, and connection failures.
+
+`connection.serverBundleId` and `connection.serverBundleSha256` identify the server publication running the connected session. These read-only diagnostics are `null` before a live connection, while disconnected, in solo mode, or when the host does not provide them. The ID identifies a publication; the SHA-256 identifies its code bytes, so two publications can share a hash. Read the values again after a reconnect or a destination join. They describe the running server, not the client bundle or the deck’s newest save.
+
+Experimental: `Multiplayer.join({ mode: "public", pongTimeoutMs: 10_000 })`
+reconnects if a keepalive ping receives no pong within the given milliseconds.
+Omitting the option (or passing `0`) preserves the existing keepalive behavior.
+The deadline starts at a ping, normally sent every 25 seconds; it is not a
+deadline for game messages. A deadline callback delayed by more than one second (for example during page
+suspension) sends one fresh ping and waits a full deadline before reconnecting. Only one
+such extension is allowed without a pong, so repeated timer throttling cannot
+postpone recovery indefinitely.
+
 During local development, reloading a Play panel restores that panel's session
 when its dev server is still running. A separate Play panel joins separately.
 
@@ -147,10 +162,34 @@ export default {
 
 `session.storage.deck` is shared by everyone playing.
 `session.storage.user(userId)` is one player's public data.
+`await session.storage.playthrough(userId)` opens that player's generation-bound
+game state. Its `resetGeneration` is present only after an administrator has
+reset that player's progress for this deck. It is a monotonic reset marker,
+separate from the handle's `generation`, which fences playthrough operations.
+Deck-scope storage writes are not fenced by either generation; a server using
+`session.storage.deck` must discard its own stale queued writes and cached
+per-player values when it observes a newer reset marker.
 `session.storage.board(name)` is a leaderboard. The root and its buckets also
 support the [atomic save API](#atomic-saves). Each scope has the same
 `get`, `set`, `remove`, `increment` and `list` as `Store`.
 
+`session.storage.town(userId)` lets a door deck's server read and write one
+signed-in player's rows in its source town's deck scope, for things such as
+hats bought in town. It has `get`, `set`, `remove` and `increment`; quota counts
+against the town. Every key is one of the town's per-player namespaces
+(`tokens`, `spent`, `own`, `hat`, `chirp`) followed by the user id: for user
+`7`, `own:7:tophat` and `hat:7` work; `own:tophat:7` and `quay:7` do not. The
+rest of the town's rows are its own. The player must be live in this session
+(a player who joined a few seconds ago can briefly get
+`CAULDRON_HUB_NOT_IN_SESSION`, so retry later rather than giving up); in a house, only the owner's rows are
+accessible. Calls reject with `CAULDRON_HUB_NO_TOWN` without a source town
+(including a town calling it), `CAULDRON_HUB_NOT_IN_SESSION` for an absent
+player, or `CAULDRON_HUB_NOT_OWNER` for someone other than the house's owner.
+Invalid key segments reject with `CAULDRON_STORAGE_INVALID_ARGUMENT`.
+During dev serve, keys live under `town/` in the dev deck's own deck scope,
+so testing a door never changes a real town. An unpublished deck still needs
+a published deck id for storage.
+
 Two differences follow from a session server not being a player:
 
 - **It owns `deck` scope.** Once a deck has a published server, clients read
@@ -173,8 +212,16 @@ kit's contract). `save-deck` publishes the block's titles and result shapes with
 the server bundle, and Castle pins them to every session of the place. Those
 sessions have `session.hub`; every other session has `session.hub === null`.
 
+`session.hub.owner` is the owner's user id string on an owner door instance,
+passed by the platform. It is absent on every other hub session, including the
+dev serve.
+
 - `session.hub.place`, `.title` and `.result` are the place and the result shape
   as published (`result` is `null` for a place that reports none, such as a town).
+- `session.hub.reconnectWindowMs`, when present, is Castle's pinned hub-place
+  reconnect grace in milliseconds, inclusive at the deadline. It is absent on
+  sessions without a pinned grace and older hosts. Kits use it to match visit retention to the
+  transport window; deck code does not choose it.
 - `session.hub.arrival(playerId)` is how a player came in when Castle placed them
   through a hub door: `{ fromDeckId, doorId }` (`doorId` is `null` when the door
   names none), else `null`. It is Castle's word, never a client's, and it is also
@@ -199,6 +246,46 @@ sessions have `session.hub`; every other session has `session.hub === null`.
   id the kit draws, `color` `'#rrggbb'`, `rarity` 0-9), or clears it with `null`;
   the latest wins. Castle takes it only from a curated hub place. Resolves
   `{ wearable }`; `readResults` returns it as `players[userId].wearable`.
+- `session.hub.unlock(playerId, itemId)` gives a signed-in player one of the
+  deck's declared earned items (castle.json `hub.unlocks`: `{ id, class, shape,
+  name, deed, color }`, at most 8, `class` one of `badge`, `pin`, `belt`, `sash`,
+  `held`). v1.70 also permits up to 6 home items separately: `furniture` or
+  `deed`, with `piece` in place of `shape` (the same lowercase id format).
+  Each id is unique across both lists. Castle takes it only from a curated hub
+  place and only for an id the saved deck declares; a first wearable unlock
+  is also shown. Resolves
+  `{ unlocked: true, isNew, earned }`, where `earned` is what the player now
+  shows (`{ deckId, id, class, shape, name, deed, color }`) or `null`, including
+  for home grants. A home grant never changes what the avatar shows; a home
+  item appears only in the owned list returned by `readUnlocks`.
+  `readResults` returns the shown one as `players[userId].earned`, absent when
+  none.
+- `session.hub.wearEarned(playerId, { deckId, id } | null)` chooses which owned
+  earned item a player shows, or none. Castle takes it only from the town.
+  Home items are refused with `CAULDRON_HUB_EARNED_NOT_WEARABLE`.
+  Resolves `{ earned }`.
+- `session.hub.readUnlocks(userIds)` reads the earned items players here own:
+  `{ players: { [userId]: { owned: [...] } } }`, including home items with
+  their `class` and `piece`. `MultiplayerHubEarnedItem` and
+  `MultiplayerHubEarnedClass` describe wearable items only;
+  `MultiplayerHubHomeItem` and `MultiplayerHubHomeClass` describe home items.
+  Only the owned list uses the union of both item types; unlock/wear receipts
+  and arrival results keep the wearable-only type.
+- These three reject with `CAULDRON_HUB_UNAVAILABLE` on a runtime without them.
+- `session.hub.friendsAmong(playerId, userIds)` resolves the subset of candidate
+  user ids that are this connected player's friends (`Promise<string[]>`).
+  The platform checks mutual follows, age, blocks, the hub gate and the player's
+  recent client friends ask. It uses `hubFriendsAmong` or the older runtime's
+  storage broker and rejects on platform errors. The hub-game kit wraps it with
+  decimal-id filtering, a 100-candidate cap, caching and a silent `[]` fallback.
+- `session.hub.relationsAmong(playerId, userIds)` makes the same single host read
+  and resolves `{ friends, follows, followedBy }`, each limited to asked string
+  ids. Missing lists are empty on older hosts. Mutual friends keep the chat age
+  and block rules; follows in either direction require no block, with no age rule.
+  These lists belong to the viewer only and must never go to another client.
+  Optional third argument `{ strict: true }` rejects malformed raw lists before
+  normalization and adds `validated: true` to a successful result. Without it,
+  the existing response shape and older-host behavior remain unchanged.
 - `session.hub.hiddenPair(playerIdA, playerIdB)` is true when a block hides these
   two players from each other (either one blocked the other). Never send either
   one the other's pose, avatar or name. The block lists themselves never reach
@@ -567,6 +654,61 @@ claim can fail with writer loss while `committed === true` and its original
 receipt; it never takes ownership again. Transport ambiguity keeps the outcome
 unknown until receipt lookup or identical replay settles it.
 
+### Conditional writes and recovery (gated)
+
+`Store.conditionalWrite(input)` and `session.storage.conditionalWrite(input)`
+use the same request and receipt as `transaction`. Read with `snapshot`, then
+pass its `access` and each target's `revision` as `expectedAccess` and
+`expectedRevision`. Use `null` to create an absent target. A revision belongs
+to a **prefix**, so changing any key in it changes the revision. For an
+independent value, give it a separate, non-overlapping prefix.
+
+This additive API is off by default. The platform must enable conditional
+storage for the deck after its database index and host support are ready.
+Older hosts and the dev memory store do not support it. Keep a dependent
+feature off when the API is unavailable; never fall back to ordinary writes.
+Existing `get`, `set` and save methods keep their behavior.
+
+One call changes up to eight targets, with up to eight explicit key changes
+per target, across the same deck and at most two players. Every target needs
+its expected revision. A read-only `check` can use `expectedRevision: null`
+to require absence without creating that target. All changes commit together. Clients may address their
+own user/private targets and writable deck targets; only the deck server can
+condition on another player's user target. Servers cannot access private data.
+Existing quota, byte and rate allowances still apply. A prefix replacement
+also removes its previous rows, subject to those allowances.
+
+On a revision conflict, `SaveError.code` is
+`CAULDRON_STORAGE_REVISION_CONFLICT`, `committed` is `false`, and `current`
+contains the current values and revisions read at the failed comparison.
+If that full snapshot exceeds the byte allowance, the call fails with
+`CAULDRON_STORAGE_TOO_LARGE`; no changes commit. Keep the player's proposed
+change and reload before offering another choice.
+
+Use a unique `operationId` for each action. Retrying the **identical request**
+after a lost reply returns its original committed receipt, even if values
+have since changed. Reusing the ID with different input is refused. Failed
+comparisons do not create receipts. Receipts have no automatic expiry and
+are retained beyond 24 hours; an explicit data/account reset may remove them.
+Never reuse old operation IDs or access tokens after a reset.
+
+`recentOperations({ limit?, cursor? })`, on both root APIs, discovers the
+caller's committed operation IDs after a restart. It returns
+`{ operations: [{ operationId, committedAt, receipt }], cursor }`, newest
+first. `limit` defaults to 16 and is at most 32; pass the returned cursor for
+the next page. This lists existing save receipts too. Client and server
+histories are separate; all layers of the same deck share the server history.
+Use a smaller limit if the reply exceeds the byte allowance. A history page
+is discovery, not a snapshot of current values: reload with `snapshot` before
+building the next change. `operation(id)` still looks up a known ID.
+
+Pairing can atomically create a project and reserve both players' recovery
+entries. The game server must still validate consent, membership and editing
+leases. A market sale can atomically update stock, the daily cap and the
+purse, once **every** writer of those values uses the managed targets.
+Durable game recovery entries belong in those targets; recent operation
+receipts alone do not define permanent project ownership or sale policy.
+
 ### Save coordinator
 
 `createSaveCoordinator`, from `castle-web-sdk` or `castle-web-sdk/server`,
@@ -895,7 +1037,7 @@ itself (ones Castle runs across decks), on the serve only.
 
 The player's platform avatar: one per account, worn in every hub place
 (cauldron-game-server `docs/HUB.md`, decision 4). In v1 it is an index into the
-hub-game kit's character templates; there is no editor and no cosmetics. The
+hub-game kit's character templates, with an optional colour choice. The
 hub-game kit is the caller: it dresses the player and offers the choice in its
 picker. Other players' avatars are not read here; a place's server learns them
 from ghost.
@@ -907,7 +1049,7 @@ every account has (`chosen: false`). Anonymous accounts have one too.
 `{ status: "unavailable", avatar: null }` for a signed-out visitor; a host from
 before avatars rejects with `UNKNOWN_COMMAND`. Either way the deck picks its own.
 
-### `Avatar.set(avatar): Promise<AvatarResult>`
+### `Avatar.set(avatar, options?: { color?: number }): Promise<AvatarResult>`
 
 Makes `avatar` the account's from now on, everywhere. Only a curated hub place
 (a deck an enabled hub door leads into or out of) may: anywhere else, and for a
@@ -915,6 +1057,15 @@ signed-out visitor, the answer is `unavailable` and nothing changes. Ghost
 refuses an index outside its template set (`INVALID_ARGUMENT`) and more than 30
 choices a minute (`RATE_LIMIT_EXCEEDED`).
 
+A host that supports avatar colours includes `color` in `AvatarResult`; the
+field is absent from older hosts. `Avatar.colors === true` marks an SDK whose
+`Avatar.set` carries `{ color }`; the hub-game kit requires both the host field
+and this marker to offer platform colours. Only after that support is known, pass
+`{ color }` to choose a non-negative integer colour for the current avatar.
+The host accepts 0–255; ghost holds the offered range. Changing character
+without options clears its colour. Omitting colour sends the existing command
+and mutation unchanged. The read query will ask for colour once ghost serves it.
+
 ## Pass
 
 A pass is something a creator sells to players for Castle bricks (the
@@ -1008,14 +1159,111 @@ Snapshot.onTaken(() => {
 });
 ```
 
+## Social
+
+`Social` gives a Cauldron deck the signed-in player's mutual Castle follows.
+The host supplies the player and current deck from trusted play context; a deck
+cannot ask about another account or deck. A host from before Social rejects with
+`CastleError` code `UNKNOWN_COMMAND`.
+
+- `Social.friends()` returns at most 20 mutual follows as
+  `{ userId, username, photoUrl? }`. A one-way follow is not a friend here.
+- `Social.presence()` returns the mutual friends playing this deck now as
+  `{ userId, username, photoUrl?, sessionId, routeId?, slot?, updatedAt }`.
+  Castle's now-playing privacy and multiplayer gates apply. It fails closed to
+  `[]` when presence is gated or unavailable.
+
+Presence has no event in v1. Poll `Social.presence()` when the game needs to
+refresh its list; do not treat `updatedAt` as a durable offline record.
+
+```js
+import { Social } from "castle-web-sdk";
+
+const friends = await Social.friends();
+const playingHere = await Social.presence();
+```
+
+## Party
+
+`Party` creates and drives Castle parties with the signed-in player's account.
+Castle still enforces membership, roles, age and party permissions; refusals are
+`CastleError`s carrying the server's code. Party and user-id arrays are bounded
+to 32 users.
+
+- `Party.current()` returns the party this play was launched with as
+  `{ partyId, name, status, hasUnreadMessages }`, or `null`. The party id comes
+  only from trusted host context, and no request is made when the play has none.
+- `Party.create(userIds)` creates a party containing those users and the
+  signed-in player. It never sets an initial deck. Creating one does not change
+  `Party.current()` or the launch party used by
+  `Multiplayer.join({ mode: "party" })`.
+- `Party.invite(partyId, userIds)` invites more users.
+- `Party.respond(partyId, accept)` accepts or rejects an invitation.
+- `Party.members(partyId)` returns
+  `{ userId, username, photoUrl?, status, role }` rows. `role` is `member`,
+  `host` or `owner`.
+- `Party.leave(partyId)` leaves the party.
+- `Party.messages(partyId, cursor?)` returns
+  `{ messages, cursor }`. Messages are newest first; pass the cursor to load
+  **older** history (the opposite direction from `Hub.chat(after)`). Each message
+  has `{ id, fromUserId, fromUsername, body, text, createdAt }`. `body` is the
+  Castle chat JSON; `text` is non-null only when that body is plain text with no
+  tags, links or embeds.
+- `Party.say(partyId, text)` sends plain text to the party. The host trims it
+  and caps it at 1,000 characters, then returns the stored `PartyMessage`.
+
+```js
+import { Party } from "castle-web-sdk";
+
+const party = await Party.current();
+if (party) {
+  const page = await Party.messages(party.partyId);
+  await Party.say(party.partyId, "Meet by the gate!");
+}
+```
+
 ## Hub
 
+Hub contract v1.95 adds optional invites. A place declaring `hub.invite: true`
+can call `hub.invite(playerId)` on its server to offer **Invite a friend**.
+The hub kit asks `Hub.invite()` for a link; `Hub.invite({ crew: true })` makes
+a crew link for up to five invitees. Links expire within 24 hours and default
+to one invitee. Hosts without invite support return `unavailable`.
+
+The trusted host resolves the link after sign-in, retains its token, and requests
+the inviter's layer when it has room. An invite can also route through the
+existing `Hub.inviteArrival()` result `{ status: 'route', doorId }` to the
+inviter's house or active run behind a curated door that allows late joins.
+Contract v1.113 active-run routing requires root `hub.bringFriend: true`
+in addition to `invite: true` on both the town and destination. The destination
+also declares `hub.bringFriend: true` so its saved bundle and fresh pin retain
+the invite capability;
+it admits only to the matching live run while the inviter is present. A full,
+ended or unavailable run is refused rather than recreated. The kit calls
+`Hub.inviteArrival()` after joining that destination. Ghost verifies arrival
+before creating mutual follows among the eligible
+over-13 members of that link. Under-13 arrivals create no follows. The arrival
+surface shows an authored now-friends line and `Hub.undoInvite(userId)` removes
+both follow directions for that pair. No player-entered message travels with a link.
+These operations retain the existing hub access gates. Link creation and arrival
+completion wait up to 16 seconds when the server presence roster is still catching
+up with the game connection.
+
 `Hub` moves a player between hub places: every deck built on the hub-game kit is
 a place, and a door is a row in Castle's curated door table. A deck names only a
 door; the host supplies the current place, the session it joined there and the
 party, and calls Castle with the player's own account. Hosts without hub support
 answer `unavailable`; older hosts reject with `CastleError` code `UNKNOWN_COMMAND`.
 
+`Hub.signIn({ reason })` asks the host to open its native sign-in flow for an
+anonymous player. `reason` is the short explanation shown to the player (at most
+200 characters and 512 UTF-8 bytes). It resolves to
+`{ status: 'signedIn', userId? }`, `{ status: 'dismissed' }`, or
+`{ status: 'unavailable' }`. `userId` is present only when the host can return
+the signed-in account id. A new host without native sign-in support returns
+`unavailable`; an older host that does not know this command rejects with
+`UNKNOWN_COMMAND`.
+
 - `Hub.doors()` reads the current place's doors and who is inside them:
   `{ status: "ok", doors }` or `{ status: "unavailable", doors: null }`. A row has
   `doorId`, `launcherKind` (`door`, `table`, `cabinet`, `gate`), `placementKind`
@@ -1444,6 +1692,13 @@ startGame(saved ?? newGame());
 Lifecycle.ready();
 ```
 
+## Display
+
+`getDisplay()` returns a `DeckDisplay`. Its optional `orientation` field is the
+deck's preferred display orientation: `landscape`, `portrait`, or `any`.
+Missing or unrecognized preferences mean `any`; read the value as
+`display.orientation ?? "any"`.
+
 ## Setup
 
 Startup, editor-mode check, and a file-write call for editor UI.
@@ -1625,3 +1880,22 @@ Common codes:
   that lacks it.
 - `CAULDRON_STORAGE_STALE_GENERATION` — the handle belongs to an older reset
   generation; reopen explicitly rather than replaying work into the new one.
+
+### Your games: hub hearts
+
+`Hub.hearts()` returns `{ status: 'ok', hearts: string[] }` for the signed-in
+account. `Hub.setHearts(doorIds)` replaces that list with at most eight distinct
+door ids, oldest first. The host supplies the current deck id; only curated hub
+places may save hearts. Guests and unavailable hosts return
+`{ status: 'unavailable', hearts: [] }`; older hosts throw `UNKNOWN_COMMAND`.
+Invalid lists throw `INVALID_ARGUMENT`, and other host failures use `CastleError`.
+The dev serve keeps hearts per account in memory until it stops.
+
+Server hub analytics (hub-game contract v1.93): `session.hub.track(playerId,
+{ kind, subject?, value?, result?, flags? })` sends a numeric event through the
+server's authenticated platform channel. It returns `Promise<boolean>`: `true`
+acknowledges queueing, while unsupported hosts and refused delivery return `false`.
+It never throws. Only opted-in hub bundles are recorded; Ghost stamps the player
+and town from the session and door pin and excludes the town creator's own plays.
+The hub-game kit exposes `hub.track(playerId, eventName, properties)` only on
+places declaring `hub.analytics: true`; see its contract for the numeric vocabulary.

package/dist/avatar.d.ts

@@ -1,12 +1,16 @@
 import type { AvatarResult } from "./commands";
 export type { AvatarResult } from "./commands";
 export interface CastleAvatarApi {
+    /** Present only in an SDK whose Avatar.set carries { color }; the hub-game kit offers colours only when it is here. */
+    readonly colors?: true;
     /**
      * The player's avatar: their choice, or the default every account has.
      * `unavailable` for a signed-out visitor, or on a host without avatars.
      */
     get(): Promise<AvatarResult>;
-    /** Choose the avatar this player wears everywhere from now on. */
-    set(avatar: number): Promise<AvatarResult>;
+    /** Choose the avatar, and optionally its colour, worn everywhere. Requires a host with colours for options.color. */
+    set(avatar: number, options?: {
+        color?: number;
+    }): Promise<AvatarResult>;
 }
 export declare const Avatar: CastleAvatarApi;

package/dist/avatar.js

@@ -1,17 +1,17 @@
 // Avatar — the player's platform avatar (cauldron-game-server docs/HUB.md,
 // decision 4): one per account, worn in every hub place. v1 is an index into the
-// hub-game kit's character templates; there is no editor and no cosmetics.
+// hub-game kit's character templates, with optional colour choices.
 //
 // The hub-game kit is the one caller: it reads the avatar to dress the player
 // and offers the choice in its picker. Other players' avatars are not read
 // here; a place's server learns them from ghost.
 import { CastleError } from "./errors";
 import { hostRequest } from "./transport";
-export const Avatar = { get, set };
+export const Avatar = { get, set, colors: true };
 async function get() {
     return hostRequest("avatar.get", {});
 }
-async function set(avatar) {
+async function set(avatar, options) {
     if (typeof avatar !== "number" || !Number.isInteger(avatar) || avatar < 0) {
         throw new CastleError({
             code: "INVALID_ARGUMENT",
@@ -19,5 +19,13 @@ async function set(avatar) {
             operation: "Avatar.set",
         });
     }
-    return hostRequest("avatar.set", { avatar });
+    const color = options?.color;
+    if (color !== undefined && (!Number.isInteger(color) || color < 0)) {
+        throw new CastleError({
+            code: "INVALID_ARGUMENT",
+            message: "Avatar.set requires a non-negative integer colour.",
+            operation: "Avatar.set",
+        });
+    }
+    return hostRequest("avatar.set", color === undefined ? { avatar } : { avatar, color });
 }

package/dist/castle.d.ts

@@ -13,7 +13,11 @@ export { deckPrefixOf, IMPORTS_DIR, IMPORTS_PREFIX, isImportedFile, resolveDeckF
 export { Haptics } from "./haptics";
 export type { CastleHapticsApi, HapticsResult, HapticsStatus, HapticStyle } from "./haptics";
 export { Hub } from "./hub";
-export type { CastleHubApi, HubBackResult, HubCancelResult, HubCancelStatus, HubChatMessage, HubChatResult, HubDoor, HubDoorsResult, HubFriend, HubFriendsResult, HubGoParams, HubGoResult, HubHandoffResult, HubHandoffStatus, HubJumpResult, HubPlacementKind, HubReportResult, HubSayResult, } from "./hub";
+export type { CastleHubApi, HubBackResult, HubCancelResult, HubCancelStatus, HubChatMessage, HubChatResult, HubDoor, HubDoorsResult, HubFriend, HubFriendsResult, HubInviteResult, HubInviteArrivalResult, HubHeartsResult, HubGoParams, HubSignInParams, HubSignInResult, HubGoResult, HubHandoffResult, HubHandoffStatus, HubJumpResult, HubPlacementKind, HubReportResult, HubSayResult, } from "./hub";
+export { Social } from "./social";
+export type { CastleSocialApi, SocialFriend, SocialPresence } from "./social";
+export { Party } from "./party";
+export type { CastlePartyApi, PartyMember, PartyMessage, PartyMessagesResult, PartyStatus, PartySummary, } from "./party";
 export { Leaderboard } from "./leaderboard";
 export type { LeaderboardData, LeaderboardEntry, LeaderboardOptions, LeaderboardScope, LeaderboardShowOptions, LeaderboardShowResult, LeaderboardShowStatus, LeaderboardSort, } from "./leaderboard";
 export { Lifecycle } from "./lifecycle";
@@ -35,7 +39,7 @@ export type { CastlePortalApi, PortalOpenResult, PortalOpenStatus, PortalPrefetc
 export { CARD_RATIO, deleteFile, fileUrl, initCard, onBeforeRestart, onFilesChanged, onSaveReloadState, openFile, renameFile, requestReload, setup, takeReloadState, writeFileOnce, } from "./runtime";
 export type { FileChange, FilesChangedEvent } from "./runtime";
 export { cardUnit, fitStage, fovForAspect, getDisplay } from "./display";
-export type { DeckDisplay, DeckLayout } from "./display";
+export type { DeckDisplay, DeckLayout, DeckOrientation } from "./display";
 export { flushSaves, hasPendingSave, onSaveState, writeFile, } from "./saveQueue";
 export type { SaveState } from "./saveQueue";
 export { SharedStorage, Storage } from "./storage";
@@ -49,4 +53,4 @@ export type { CastleUser, CastleUserApi } from "./user";
 export { createSaveCoordinator } from "./saveCoordinator";
 export type { CoordinatedChange, CoordinatedSave, SaveCoordinator, SaveStatus, } from "./saveCoordinator";
 export { SaveError } from "./save";
-export type { SaveApi, SaveBucketApi, SaveBucketRead, SaveChange, SaveCheck, SaveClaimed, SaveClaimInput, SaveErrorEnvelope, SaveInitial, SaveInitializeInput, SaveOpened, SaveOperation, SaveReadTarget, SaveReceipt, SaveRevision, SaveRows, SaveScope, SaveSelection, SaveSnapshot, SaveTarget, SaveTransactionInput, SaveWriter, } from "./save";
+export type { SaveApi, SaveBucketApi, SaveBucketRead, SaveChange, SaveCheck, SaveConditionalCheck, SaveConditionalWriteInput, SaveClaimed, SaveClaimInput, SaveErrorEnvelope, SaveInitial, SaveInitializeInput, SaveOpened, SaveOperation, SaveReadTarget, SaveReceipt, SaveRecentOperationsInput, SaveRecentOperationsPage, SaveRevision, SaveRows, SaveScope, SaveSelection, SaveSnapshot, SaveTarget, SaveTransactionInput, SaveWriter, } from "./save";

package/dist/castle.js

@@ -9,6 +9,8 @@ export { experiment, experiments, experimentsReady } from "./experiments";
 export { deckPrefixOf, IMPORTS_DIR, IMPORTS_PREFIX, isImportedFile, resolveDeckFile, } from "./files";
 export { Haptics } from "./haptics";
 export { Hub } from "./hub";
+export { Social } from "./social";
+export { Party } from "./party";
 export { Leaderboard } from "./leaderboard";
 export { Lifecycle } from "./lifecycle";
 export { Multiplayer } from "./multiplayer";