@matchi/api 0.20260826.3 → 0.20260828.1

package/dist/main/index.d.mts

@@ -1631,7 +1631,9 @@ declare namespace playSessionSettings {
  * * `RIGHT` - The right spot, when each team has two.
  * On a `users` entry (`requestedPosition`) this is the spot the player asked for. It is a preference, not a
  * reservation: it is resolved against the layout when the request is made and again when the player is confirmed
- * or approved, and the player may end up on a different spot if this one was taken meanwhile.
+ * or approved, and the player may end up on a different spot if this one was taken meanwhile. A confirming or
+ * approving request that names a spot of its own decides the placement outright and this preference is not
+ * consulted — see `teamId` on `playsessionUserDetails`.
  *
  */
 declare enum spotPosition {
@@ -1800,6 +1802,11 @@ type playsessionUserDetails = {
      * with `409`, so the client can offer another; if the spot is taken later, before the player is
      * approved or confirms, they are placed on the next best spot instead.
      *
+     * A named spot always decides the placement, including on the `POST` that approves a pending request or
+     * confirms a participation: the spot named there is the one the player is seated on, whatever they asked
+     * for on the way in, and a `409` is the answer when it has gone rather than a move to the next best spot.
+     * Naming nothing there is what falls back to the preference stored from the original request.
+     *
      * Ignored on a play session with no team layout, since there is then no spot to address. Whether
      * team handling is enabled for the venue does not come into it — that decides whether the `teams`
      * structure is served, not whether a claim is honoured. Only honoured on `POST` — a seated player is

package/dist/main/index.d.ts

@@ -1631,7 +1631,9 @@ declare namespace playSessionSettings {
  * * `RIGHT` - The right spot, when each team has two.
  * On a `users` entry (`requestedPosition`) this is the spot the player asked for. It is a preference, not a
  * reservation: it is resolved against the layout when the request is made and again when the player is confirmed
- * or approved, and the player may end up on a different spot if this one was taken meanwhile.
+ * or approved, and the player may end up on a different spot if this one was taken meanwhile. A confirming or
+ * approving request that names a spot of its own decides the placement outright and this preference is not
+ * consulted — see `teamId` on `playsessionUserDetails`.
  *
  */
 declare enum spotPosition {
@@ -1800,6 +1802,11 @@ type playsessionUserDetails = {
      * with `409`, so the client can offer another; if the spot is taken later, before the player is
      * approved or confirms, they are placed on the next best spot instead.
      *
+     * A named spot always decides the placement, including on the `POST` that approves a pending request or
+     * confirms a participation: the spot named there is the one the player is seated on, whatever they asked
+     * for on the way in, and a `409` is the answer when it has gone rather than a move to the next best spot.
+     * Naming nothing there is what falls back to the preference stored from the original request.
+     *
      * Ignored on a play session with no team layout, since there is then no spot to address. Whether
      * team handling is enabled for the venue does not come into it — that decides whether the `teams`
      * structure is served, not whether a claim is honoured. Only honoured on `POST` — a seated player is

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@matchi/api",
-  "version": "0.20260826.3",
+  "version": "0.20260828.1",
   "main": "dist/main/index.js",
   "module": "dist/main/index.mjs",
   "devDependencies": {