juicyjuicy 0.11.0 → 0.11.1

package/dist/index.js

@@ -19807,7 +19807,7 @@ function date4(params) {
 }
 
 // ../shared/src/cli.ts
-var CLI_RELEASE = "0.11.0";
+var CLI_RELEASE = "0.11.1";
 function cliCommand(args) {
   return `npx -y juicyjuicy@${CLI_RELEASE} ${args}`;
 }
@@ -26456,7 +26456,7 @@ var program = new Command();
 // package.json
 var package_default = {
   name: "juicyjuicy",
-  version: "0.11.0",
+  version: "0.11.1",
   description: "Publish AI-made browser games to juicyjuicy.games",
   type: "module",
   license: "MIT",

package/dist/skill/SKILL.md

@@ -9,19 +9,19 @@ JuicyJuicy hosts **static browser games** (HTML/JS/CSS/assets, WebAssembly) and
 
 Run every CLI command with `--json`. Each output line is a JSON object; the **last** line is the result, either `{"ok": true, …}` or `{"ok": false, "error": {"code", "message", "details"?, "hint"?}}`. The exit code is `0` (ok), `1` (fix the game or `juicy.json`), `2` (log in) or `3` (network or server problem, so retry).
 
-Run the CLI exactly as written here, `npx -y juicyjuicy@0.11.0 …`: this skill is made for that release. If JuicyJuicy answers that the CLI is out of date, run the command its message gives. It updates the CLI and this skill together; read this skill again afterwards and use the release it names from then on.
+Run the CLI exactly as written here, `npx -y juicyjuicy@0.11.1 …`: this skill is made for that release. If JuicyJuicy answers that the CLI is out of date, run the command its message gives. It updates the CLI and this skill together; read this skill again afterwards and use the release it names from then on.
 
 ## Procedure
 
 ### 1. Make sure the CLI is logged in
 
 ```bash
-npx -y juicyjuicy@0.11.0 whoami --json
+npx -y juicyjuicy@0.11.1 whoami --json
 ```
 
 If it exits with `2`, log in. `login` opens the user's browser and **waits up to 10 minutes** for them to approve:
 
-- Run `npx -y juicyjuicy@0.11.0 login --json` in the background if your shell can, and read its first output line (`{"event": "device_code", "userCode", "verificationUrl"}`) right away, and show the user the code and link without waiting for them to ask: the page shows the same code, and that's how they know the login is theirs.
+- Run `npx -y juicyjuicy@0.11.1 login --json` in the background if your shell can, and read its first output line (`{"event": "device_code", "userCode", "verificationUrl"}`) right away, and show the user the code and link without waiting for them to ask: the page shows the same code, and that's how they know the login is theirs.
 - Then tell the user, with the real code and link: *"A JuicyJuicy page opened in your browser. Check it shows the code **WXTZ-BCDF** and click **Approve**. If no page opened, go to <verificationUrl>."*
 - If your shell can't run commands in the background, say that first (without a code: it doesn't exist yet), then run it in the foreground with a timeout of at least 10 minutes. The code is also printed as `Your code: …`.
 - The user needs a JuicyJuicy account (it's invite-only for now). If the page says they can't sign in, they need an invite link from a friend who's a member.
@@ -45,7 +45,7 @@ Files and folders starting with `.` (`.env`, `.git/`, …) and `node_modules/` a
 `juicy.json` sits in the project folder and describes the game. Create or update it with `init`, filling in what you know from the game you built:
 
 ```bash
-npx -y juicyjuicy@0.11.0 init --yes --json \
+npx -y juicyjuicy@0.11.1 init --yes --json \
   --title "Snake Deluxe" \
   --description "Eat the apples, don't bite your tail. Arrow keys or swipe." \
   --made-with "<your model name>, <the tool you run in>" \
@@ -85,7 +85,7 @@ To replace it, the user saves a screenshot as `thumbnail.png` in the project fol
 
 Do this **every time**, also for updates. It protects the user and their players; JuicyJuicy's server runs its own checks as well, so this is help, not a formality to get past.
 
-1. **Check.** Run `npx -y juicyjuicy@0.11.0 check --json`. Errors (a failed result) must be fixed: explain each one (`details` has a `rule` and a `path`), and offer to fix it. If the user says no, **stop and don't publish**: the server would refuse it anyway. Warnings in the result (`findings`) go into step 2.
+1. **Check.** Run `npx -y juicyjuicy@0.11.1 check --json`. Errors (a failed result) must be fixed: explain each one (`details` has a `rule` and a `path`), and offer to fix it. If the user says no, **stop and don't publish**: the server would refuse it anyway. Warnings in the result (`findings`) go into step 2.
    Every file in the result's `files` will be public. If `unusualFiles` isn't empty (names that look like keys or private data, project files like `package.json`, notes and other files a web game doesn't load), **show the user that list and ask whether those files should be public** before publishing; offer to move them out of the build folder or set `buildDir` to a folder with just the game.
 2. **Security review.** Follow [reference/review.md](reference/review.md): keys and tokens, `innerHTML`/`eval` on network or multiplayer data, `http://` loads, trackers, login or payment forms, anything that leaves the page. Same rule: for what it marks as must-fix, fix it or don't publish.
 3. **Standards.** Check the game against these and tell the user, in a sentence or two, what falls short; offer to fix it. A "no" still publishes: not every game can have touch controls.
@@ -114,7 +114,7 @@ Keep it short when there's nothing to say: "Checked: no problems found" is enoug
 ### 6. Publish
 
 ```bash
-npx -y juicyjuicy@0.11.0 publish --json --message "<what changed, in a few words>"
+npx -y juicyjuicy@0.11.1 publish --json --message "<what changed, in a few words>"
 ```
 
 This makes the new version live: when the user says "publish", that's what they want. Don't add `--draft` (see "Other commands") unless they asked in words for it not to go live yet. Not for a first publish, a big game or one you're unsure of either: the user would have to find the dashboard and make it live themselves.
@@ -141,7 +141,7 @@ The game's page under My games on JuicyJuicy has an **Upgrades** panel; its Add
 
 Other features on the panel (touch controls, gamepad, mouse lock, auto-pause) are "Coming soon" and have no recipe yet: if asked for one, say so, and build it your own way only if the user wants.
 
-1. **Find the project.** Log in first (step 1). The project is the folder whose `juicy.json` has the game's `slug`: the current folder, or one the user points you to. **If it isn't on this computer** (or you're in a chat app or sandbox), download the live version: `npx -y juicyjuicy@0.11.0 pull <slug> --json` writes it into a new folder named after the slug (`dir` in the result) with its `juicy.json`, and you work there. Read the result's `next`: the download is the built game, so for a bundled one (minified code), ask whether the user has the source somewhere, or use `sourceUrl`, before changing the bundle itself. `pull` only works for the user's own games (`NOT_FOUND` otherwise).
+1. **Find the project.** Log in first (step 1). The project is the folder whose `juicy.json` has the game's `slug`: the current folder, or one the user points you to. **If it isn't on this computer** (or you're in a chat app or sandbox), download the live version: `npx -y juicyjuicy@0.11.1 pull <slug> --json` writes it into a new folder named after the slug (`dir` in the result) with its `juicy.json`, and you work there. Read the result's `next`: the download is the built game, so for a bundled one (minified code), ask whether the user has the source somewhere, or use `sourceUrl`, before changing the bundle itself. `pull` only works for the user's own games (`NOT_FOUND` otherwise).
 2. **Read the recipe** for the upgrade and make the change. Keep everything else about the game as it is.
 3. **Build and try it** (step 2), then **declare it** in `juicy.json` as the table says, adding to what's already listed.
 4. **Review and publish** as steps 5–7 say, with `--message "Add <upgrade>"`. In step 5's `check` result, `features.detected` lists what JuicyJuicy found in the files; a `feature-missing` warning means a declared upgrade isn't there yet: fix it before publishing.
@@ -149,14 +149,14 @@ Other features on the panel (touch controls, gamepad, mouse lock, auto-pause) ar
 
 ## Bring all my games up to date
 
-When the user asks to bring their JuicyJuicy games up to date or fix a **Needs update** badge, when `check` warns `requirement-missing`, or after updating the CLI: follow [reference/update-all-games.md](reference/update-all-games.md). It starts with `npx -y juicyjuicy@0.11.0 check-games --json`, which checks every game of the user's at once and settles what a script can; the rest are code changes, one game at a time.
+When the user asks to bring their JuicyJuicy games up to date or fix a **Needs update** badge, when `check` warns `requirement-missing`, or after updating the CLI: follow [reference/update-all-games.md](reference/update-all-games.md). It starts with `npx -y juicyjuicy@0.11.1 check-games --json`, which checks every game of the user's at once and settles what a script can; the rest are code changes, one game at a time.
 
 ## Remix a game
 
 A game marked remixable on JuicyJuicy can be downloaded, changed and published as a new game that links back to it. Log in first (step 1), then:
 
 ```bash
-npx -y juicyjuicy@0.11.0 remix <slug> --json
+npx -y juicyjuicy@0.11.1 remix <slug> --json
 ```
 
 - The first line is `{"event": "license", "name", "text"}`: the remix license. Tell the user in a sentence what it says. In short: the remix may be published **on JuicyJuicy only**, never anywhere else, and the files aren't to be passed on. The full text is:
@@ -192,9 +192,9 @@ Everything else is in [reference/troubleshooting.md](reference/troubleshooting.m
 
 ## Other commands
 
-- `npx -y juicyjuicy@0.11.0 list --json`: the user's games; `list <slug>` shows one game's versions. `--all` lists every game on JuicyJuicy instead (60 a page, `--page 2` and on; `nextPage` in the result), `--owner <username>` another creator's. Narrow and order any list with `--search <title text>`, `--tag`, `--engine`, `--remixes`, `--multiplayer` (games with rooms), `--highscores` (games with a leaderboard), `--sort newest|upvoted|downvoted|played` and `--period 24h|week|month|all`, e.g. to find a game to remix.
-- `npx -y juicyjuicy@0.11.0 publish --draft --json`: uploads a new version without making it live (players keep the current one). Only when the user asks for that in words (e.g. "upload it but don't put it live yet"), never on your own judgment. The result has `draft: true`; when they say so, make it live with `rollback <version>`, or they can on the dashboard.
-- `npx -y juicyjuicy@0.11.0 rollback <version> --slug <slug> --json`: makes an earlier version or a draft live, e.g. when the user says the last update broke the game. Run `list <slug>` first to pick the version with the user; one waiting for an admin's review can't be made live (`FORBIDDEN`).
-- `npx -y juicyjuicy@0.11.0 pull <slug> --json`: downloads the live version of one of the user's own games into a new folder with its `juicy.json`, to change it when the project isn't on this computer (see "Add a JuicyJuicy upgrade").
-- `npx -y juicyjuicy@0.11.0 check-games --json`: checks all the user's games against JuicyJuicy's features and required updates, declares the features it finds where a game never declared them, and lists what still needs a change (see "Bring all my games up to date").
-- `npx -y juicyjuicy@0.11.0 open <slug>`: opens the game page in the browser.
+- `npx -y juicyjuicy@0.11.1 list --json`: the user's games; `list <slug>` shows one game's versions. `--all` lists every game on JuicyJuicy instead (60 a page, `--page 2` and on; `nextPage` in the result), `--owner <username>` another creator's. Narrow and order any list with `--search <title text>`, `--tag`, `--engine`, `--remixes`, `--multiplayer` (games with rooms), `--highscores` (games with a leaderboard), `--sort newest|upvoted|downvoted|played` and `--period 24h|week|month|all`, e.g. to find a game to remix.
+- `npx -y juicyjuicy@0.11.1 publish --draft --json`: uploads a new version without making it live (players keep the current one). Only when the user asks for that in words (e.g. "upload it but don't put it live yet"), never on your own judgment. The result has `draft: true`; when they say so, make it live with `rollback <version>`, or they can on the dashboard.
+- `npx -y juicyjuicy@0.11.1 rollback <version> --slug <slug> --json`: makes an earlier version or a draft live, e.g. when the user says the last update broke the game. Run `list <slug>` first to pick the version with the user; one waiting for an admin's review can't be made live (`FORBIDDEN`).
+- `npx -y juicyjuicy@0.11.1 pull <slug> --json`: downloads the live version of one of the user's own games into a new folder with its `juicy.json`, to change it when the project isn't on this computer (see "Add a JuicyJuicy upgrade").
+- `npx -y juicyjuicy@0.11.1 check-games --json`: checks all the user's games against JuicyJuicy's features and required updates, declares the features it finds where a game never declared them, and lists what still needs a change (see "Bring all my games up to date").
+- `npx -y juicyjuicy@0.11.1 open <slug>`: opens the game page in the browser.

package/dist/skill/reference/languages.md

@@ -16,4 +16,4 @@ JuicyJuicy offers English, French, Italian, German, Spanish and Polish (`en`, `f
 Run the game, switch to each language and go through the menus and the first minute of play: no missing keys (an untranslated key shows up as the key's name), no clipped text, and the choice is still there after a reload.
 
 ## Declare it
-Set `languages` in `juicy.json` to every language the game now has, English first, e.g. `"languages": ["en", "fr", "pl"]` (or `npx -y juicyjuicy@0.11.0 init --yes --json --languages en,fr,pl`). Don't add it to `features`: JuicyJuicy reads `languages`, and shows the game in each language's filter.
+Set `languages` in `juicy.json` to every language the game now has, English first, e.g. `"languages": ["en", "fr", "pl"]` (or `npx -y juicyjuicy@0.11.1 init --yes --json --languages en,fr,pl`). Don't add it to `features`: JuicyJuicy reads `languages`, and shows the game in each language's filter.

package/dist/skill/reference/multiplayer.md

@@ -21,12 +21,12 @@ Don't build anything yet. **Ask the user how multiplayer should work in this gam
 
 1. **What kind of play:** together against the game (co-op), against each other (versus), taking turns, or a race or party round?
 2. **How many players:** 2 to 10.
-3. **How players join:** an **Invite** button that shares a link, a code shown on screen to type in, and/or **public rooms** anyone playing the game can find in a list and join (see "Public rooms"). Can someone join a game that has started, or only in the lobby?
+3. **How players join:** through the default menu (see "The menu"): **Multiplayer** → **Search lobby** (a list of public lobbies, plus a code box) or **Host lobby** (a lobby the host switches between Public and Private, with an Invite link). Say you'll build that unless they want something else. Can someone join a game that has started, or only in the lobby?
 4. **When someone leaves:** does the game go on without them? When the host leaves, the next player takes over (see "When the host changes"); is that right for this game?
 5. **Phones:** should it play on phones (touch controls)?
 6. **Anything else:** teams, rounds, a winner screen, what each player sees of the others.
 
-Then write the design back in a few lines: the screens (menu, lobby, game, results), what the host runs, what each player sends and what the host sends back. **Build it only once the user agrees**, then follow "Using it" and "How to build it".
+Then write the design back in a few lines: the screens (the default menu's, then game and results), what the host runs, what each player sends and what the host sends back. **Build it only once the user agrees**, then follow "The menu", "Using it" and "How to build it".
 
 ## The snippet
 Paste it as is, before the game's own code: an inline `<script>` in `index.html`, or the top of the main script. Don't change it. It works next to the cloud-saves snippet, in either order (an older copy of the cloud-saves snippet, without `window.juicy.save ||` near its top, must come first).
@@ -486,27 +486,69 @@ window.juicy.rooms || (function (juicy) {
 })(window.juicy);
 ```
 
+## The menu
+Every game gets this multiplayer menu unless the user asks for another. Build it as the game's own screens, in its own look (fonts, colors, button style), and make every screen work at phone width and by keyboard.
+
+1. **Main menu:** a **Multiplayer** button next to the game's own buttons (Play, Settings…).
+2. **Multiplayer:** two buttons, **Search lobby** and **Host lobby**, and **Back**.
+3. **Search lobby:**
+   - A small framed box listing the public lobbies from `juicy.rooms.list()`: on each row the host's login (with `textContent`), the players (`2/4`), the label in the game's own words if the game uses labels, and a **Join** button. The box keeps its size and scrolls inside when the list is long.
+   - A **refresh icon button** (↻, with `aria-label="Refresh"`) at the box's top right. The list loads once when the screen opens and again only when the player presses it (each read counts against the player's limit; never more often than every 5 seconds).
+   - Under the box, a line "Private lobby? Enter its code", a **code box** (6 letters, upper case, `maxlength="6"`) and a **Join** button; Enter in the box joins too.
+   - An empty list says so in the box ("No open lobbies. Host one!") and keeps the code box working.
+   - **Back**.
+4. **Host lobby** opens a room with `create({ max, public: true })` and goes straight to the lobby screen. **Join** from Search or the code box goes there too.
+5. **The lobby:**
+   - The **lobby code** big and spaced out (`K7QX2M`), so it can be read out.
+   - For the host only, a **Public / Private** switch: Public is listed in Search lobby; Private is only for people with the code or invite link (`room.setPublic(false)`, `room.setPublic()`), with that line under it. It starts on Public; a game meant only for friends (or a user who asks) starts on Private instead. Everyone else sees which it is as text, without the switch.
+   - The players, the host marked (a crown or "(host)"), with empty "Waiting…" slots up to `room.max` (`2/4`).
+   - **Invite** (`room.invite()`: JuicyJuicy's share sheet), **Start** for the host only (the others see "Waiting for the host"), and **Leave**.
+6. **Opened from an invite link** (`juicy.rooms.invited()`): skip the menu and join that room's lobby.
+
+Errors (a wrong code, a full room, signed out) show as a short line on the screen the player is on, which stays open. A closed room goes back to the Multiplayer screen with the reason.
+
 ## Using it
 ```js
-// Opened from an invite link: join that room straight away.
+// Opened from an invite link: join that lobby straight away.
 const code = await juicy.rooms.invited();
-if (code) start(await juicy.rooms.join(code));
+if (code) enter(() => juicy.rooms.join(code));
 
-// The menu's "Play with friends" opens a room; "Join" takes a code the player types.
-playButton.onclick = async () => start(await juicy.rooms.create({ max: 4 }));
-joinButton.onclick = async () => start(await juicy.rooms.join(codeInput.value));
+multiplayerButton.onclick = () => showScreen("multiplayer"); // Search lobby, Host lobby, Back
+hostButton.onclick = () => enter(() => juicy.rooms.create({ max: 4, public: true }));
+searchButton.onclick = () => { showScreen("search"); refresh(); };
+refreshButton.onclick = refresh; // the ↻ icon at the list's top right
+joinCodeButton.onclick = () => enter(() => juicy.rooms.join(codeInput.value));
 
-// "Find a game" lists the public rooms; "Host a public game" opens one anyone can join.
-findButton.onclick = async () => showRooms(await juicy.rooms.list()); // [{ code, host, players, max, label }]
-hostButton.onclick = async () => start(await juicy.rooms.create({ max: 4, public: true, label: "duel" }));
+async function refresh() {
+  const rooms = await juicy.rooms.list(); // [{ code, host, players, max, label }]
+  // One row per room: host login and players (textContent), and a Join button that runs
+  // enter(() => juicy.rooms.join(room.code)). None: "No open lobbies. Host one!"
+  showRooms(rooms);
+}
+
+async function enter(open) {
+  try {
+    start(await open());
+  } catch (error) {
+    showError(error.code); // a short line on this screen: wrong code, full, signed out…
+  }
+}
 
 function start(room) {
-  showLobby(room.code, room.players); // [{ id: "p1", name: "luk" }, …], with textContent
+  showScreen("lobby");
+  showLobby(room); // room.code, room.players ([{ id: "p1", name: "luk" }, …], with textContent), room.max
+  publicSwitch.hidden = !room.isHost();
+  publicSwitch.onchange = () => room.setPublic(publicSwitch.checked); // Public / Private
   inviteButton.onclick = () => room.invite(); // JuicyJuicy's share sheet, with Copy link
-  room.on("join", (player) => addToLobby(player));
-  room.on("leave", (player) => removeFromLobby(player));
-  room.on("message", (data, from) => handle(data, from));
-  room.on("close", (reason) => backToMenu(reason));
+  startButton.hidden = !room.isHost();
+  startButton.onclick = () => { room.send({ k: "start" }); room.lock(); beginGame(room); };
+  leaveButton.onclick = () => room.leave();
+  room.on("join", () => showLobby(room));
+  room.on("leave", () => showLobby(room));
+  room.on("host", () => showLobby(room)); // the new host gets the switch and Start
+  room.on("public", (isPublic) => showPublic(isPublic));
+  room.on("message", (data, from) => (data.k === "start" ? beginGame(room) : handle(data, from)));
+  room.on("close", (reason) => { showScreen("multiplayer"); showError(reason); });
 }
 ```
 
@@ -524,11 +566,10 @@ function start(room) {
 ## How to build it
 - **The host runs the game.** Players send their input (`{ k: "input", left: true }`, a move, a card played); the host applies it to the one true game state and sends the state, or what changed, to everyone. Players draw what the host sent and never decide outcomes themselves. For a real-time game, send state 10 to 20 times a second and smooth movement between updates; send input when it changes, not every frame.
 - **Small messages with a kind:** `{ k: "state", … }`, `{ k: "input", … }`. Each message is at most 16 KB as JSON, and each player may send at most 60 messages and 64 KB a second (one `send` to everyone counts once). Over that, messages are dropped (`RATE_LIMITED`), and far over it the player is disconnected (`TOO_FAST`).
-- **The lobby:** show the code and the players, an **Invite** button (`room.invite()`) and, for the host, **Start**. When the game starts, the host sends `{ k: "start", … }` and calls `room.lock()` if nobody may join mid-game.
-- **Public rooms** suit games where strangers can have a good time together: versus or party games with short rounds, drop-in co-op. Keep invite-only (the default) for games meant for friends, long sessions, or games that need everyone from the start. A game can offer both: **Play with friends** opens a private room, **Find a game** shows `list()` and **Host a public game** opens a public one.
-  - Show the list as the game's own screen: each room's host login (with `textContent`), its players (`2/4`) and its label in the game's own words, with **Join**, and a **Refresh** button. Refresh when the player asks or at most every 5 seconds while the list is showing (each read counts against the player's limit). An empty list says so and offers to host one.
+- **The lobby** is the screen in "The menu". When the game starts, the host sends `{ k: "start", … }` and calls `room.lock()` if nobody may join mid-game. If players may drop in, the host sends `{ k: "start" }` to each player who joins (`room.send(data, player.id)`) so they go straight into the game.
+- **Public and private lobbies:** Host lobby opens a public room, which Search lobby lists; the host's switch makes it private (`room.setPublic(false)`: only the code and the invite link get in) and public again (`room.setPublic()`). The `"public"` event tells everyone, so the lobby can show which it is.
   - Lock the room (`room.lock()`) when the round starts unless players may drop in: that takes it off the list. Unlock it after the round to let the next players in.
-  - A label is only the game's own id, from a fixed set in the code. **Never** put text a player typed into a label: no room names (there's no moderation; the security review treats it like free-text chat).
+  - **Labels** are optional, for a game with modes or maps in Search lobby (`create({ public: true, label: "duel" })`, `list({ label })`). A label is only the game's own id, from a fixed set in the code. **Never** put text a player typed into a label: no lobby names (there's no moderation; the security review treats it like free-text chat).
 - **When the host changes** (the host left or dropped): every player keeps the last state the host sent, so on `"host"` the new host (`room.isHost()`) carries on from it and starts sending state. A turn-based game resends whose turn it is.
 - **When a player leaves**, the host decides: remove their character, let the round finish, or end the game if too few are left.
 - **Dropped connections:** phones drop them when the game goes to the background. The snippet reconnects by itself (three tries) and keeps the player's id; during that time `send` does nothing. When the host comes back, it asks for nothing: players resend what they need on `"join"` or `"host"`.

package/dist/skill/reference/troubleshooting.md

@@ -6,7 +6,7 @@ With `--json`, a failed command's last line is `{"ok": false, "error": {"code",
 
 | Code | Meaning | Fix |
 |---|---|---|
-| `UNAUTHORIZED` | No saved login, or the token was revoked. | `npx -y juicyjuicy@0.11.0 login --json` (the user approves in the browser). In CI, set `JUICY_TOKEN`. |
+| `UNAUTHORIZED` | No saved login, or the token was revoked. | `npx -y juicyjuicy@0.11.1 login --json` (the user approves in the browser). In CI, set `JUICY_TOKEN`. |
 | `EXPIRED_TOKEN` | The login code expired (10 minutes) or was used. | Run `login` again. |
 | `ACCESS_DENIED` | The user clicked Deny. | Ask them, then run `login` again. |
 

package/dist/skill/reference/update-all-games.md

@@ -5,7 +5,7 @@ For "bring my JuicyJuicy games up to date", "fix the required updates", a **Need
 1. **Check every game at once.** Log in first (SKILL.md step 1), then run:
 
    ```bash
-   npx -y juicyjuicy@0.11.0 check-games --json
+   npx -y juicyjuicy@0.11.1 check-games --json
    ```
 
    JuicyJuicy checks the live version of each of the user's games on its side. It records which features each one has and, for a game whose `juicy.json` never listed its `features`, declares what it finds in the files (like cloud saves). Nothing is uploaded and no new version is made. The result has one entry per game in `games` (`features` with `on`/`off`/`unknown`, `requirements` with `passed`), `toFix` (the games that still need a code change, each with its `prompts`), `notReached` and `next`.
@@ -13,7 +13,7 @@ For "bring my JuicyJuicy games up to date", "fix the required updates", a **Need
 2. **If `notReached` isn't empty**, run `check-games` again: it had no time for those games.
 
 3. **For each game in `toFix`**, one at a time:
-   - Find its project, or download the live version with `npx -y juicyjuicy@0.11.0 pull <slug> --json` (SKILL.md, "Add a JuicyJuicy upgrade", step 1).
+   - Find its project, or download the live version with `npx -y juicyjuicy@0.11.1 pull <slug> --json` (SKILL.md, "Add a JuicyJuicy upgrade", step 1).
    - Do what each prompt says, with the recipe it names when it names one.
    - Make sure `juicy.json` has `features` (`[]` if the game has none of the upgrades).
    - Check and publish an update as SKILL.md steps 5–7 say, with `--message "Required update: <what>"`.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "juicyjuicy",
-  "version": "0.11.0",
+  "version": "0.11.1",
   "description": "Publish AI-made browser games to juicyjuicy.games",
   "type": "module",
   "license": "MIT",