lokiplay 0.4.0 → 0.4.2

package/dist/AGENTS.template.md

@@ -27,6 +27,21 @@
   Loki overlay shows room status, players, invite copy, and chat only; it
   does not create or join rooms. Players still need loading, waiting, and
   error states.
+- Installing the SDK also does not add Match or Leaderboard screens; both
+  are required alongside create/join, and the Loki overlay never draws
+  them. Add a Match control that calls the room wrapper's `matchmake()`
+  (`SynchronizedRoom.matchmake()` / `RealtimeRoom.matchmake()`) with
+  confirmed player/team settings, plus searching, cancel (abort the
+  in-flight search), timeout, waiting, and error states. Add a per-game
+  Leaderboard using `listLeaderboard()`/`submitLeaderboardScore()` (or the
+  in-room `submitScore()` for a mid-room board), with display-name
+  collection or a sensible fallback, plus loading, empty, pagination,
+  submission, and error states. Player count, teams, and scoring stay
+  creator decisions from the confirmed profile; if the game has no numeric
+  result to store, ask the creator once what to record instead of
+  inventing a scoring rule. Leaderboards are per-game/project and available
+  to guest sessions without a creator account; client-submitted scores are
+  not an anti-cheat boundary. Public room browsing stays optional.
 - Before configuring Loki multiplayer, inspect the game's source, existing UI,
   configuration, documentation, tests, and finished build. Locate its game
   modes, seats, local-player handling, AI opponents, teams, start conditions,
@@ -59,14 +74,49 @@
   selection, readiness, player limits, invite and join behavior, waiting
   states, and start conditions.
 - Do not invent new `game.json` fields. Current manifests accept only
-  `enabled`, `authority`, `maxPlayers`, and `tickRate`. Report the richer
-  profile in the final report: values, supporting evidence, and
-  creator-confirmed decisions.
+  `enabled`, `authority`, `maxPlayers`, `tickRate`, and — only when
+  `authority` is `"server"` — `step`. Report the richer profile in the
+  final report: values, supporting evidence, and creator-confirmed
+  decisions.
+- Classify authority from the code that advances match state, not from the
+  genre or the frame rate. Turn-based or event-driven means that state
+  changes only when a player action is committed. Continuous realtime means
+  state advances on a tick even when nobody has just pressed a button. If
+  that reading is ambiguous, stop and ask the creator what the match state
+  depends on. Do not guess.
+- One `game.json` has one `authority` for the whole project. If modes
+  disagree, say so and ask which one this project is.
+- Host is more suitable for turn-based and event-driven games. Write
+  `"authority": "host"`, omit `step`, and use `createSynchronizedRoom()`.
+- Server is more suitable for continuous realtime games. Tell the creator
+  what the update path does, then ask them to confirm server. Write
+  `"authority": "server"` and `step`. Do not elect a player host. Server
+  rooms are browser-only, run in Singapore, and end if the step fails; they
+  do not fall back to a player. That is fairness, not lower latency.
+- Before compiling `step`, change the state update so the next state depends
+  only on the previous state and this tick's inputs. Drawing, sound, and
+  asset loads stay in the browser. If the update reads the DOM, the clock,
+  randomness, or assets, remove those calls from it. A seed or the tick
+  index, when the game needs one, is an input field, not something the
+  module reads itself. If you cannot make that change, say so and do not
+  write `"authority": "server"`. Host realtime (`createRealtimeRoom()` with
+  `"authority": "host"`) can ship until the update is pure; say that is why,
+  and do not describe host as the better fit for a continuous game.
+- `step` names a compiled `.wasm` module (`modulePath`) exporting exactly
+  one function, `step`, and importing nothing — no WASI, clocks, randomness,
+  or host functions. Compile it yourself. The validator rejects imports, and
+  the worker never mounts anything else.
+- A later switch is another deploy after the creator confirms again. Rooms
+  already open keep the authority they started with.
+- Do not ask the creator to choose server, and do not write
+  `"authority": "server"`, until Loki has enabled server authority in
+  production. Until then, continuous games use host realtime. The server
+  question above applies once that switch is on.
 - After inspecting and confirming each game mode's profile, choose
   `createSynchronizedRoom()` for turn-based or event-driven state, or
-  `createRealtimeRoom()` for continuous host-authoritative simulation. Do not
-  choose by genre or animation smoothness; choose by how authoritative state
-  actually progresses. Do not run both room types for the same mode.
+  `createRealtimeRoom()` for continuous realtime. Do not choose by genre or
+  animation smoothness; choose by how authoritative state actually
+  progresses. Do not run both room types for the same mode.
 - `createSynchronizedRoom()`: define project-owned state and actions, then
   provide a reducer. Do not implement a parallel authority, version, or
   membership protocol.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "lokiplay",
-  "version": "0.4.0",
+  "version": "0.4.2",
   "description": "Command-line tools for Loki game projects and deployments.",
   "license": "MIT",
   "repository": {
@@ -39,7 +39,7 @@
     "access": "public"
   },
   "dependencies": {
-    "@lokiplay/protocol": "0.4.0",
+    "@lokiplay/protocol": "0.4.2",
     "fflate": "^0.8.3"
   }
 }