juicyjuicy 0.11.1 → 0.11.2

package/dist/index.js

@@ -19807,7 +19807,7 @@ function date4(params) {
 }
 
 // ../shared/src/cli.ts
-var CLI_RELEASE = "0.11.1";
+var CLI_RELEASE = "0.11.2";
 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.1",
+  version: "0.11.2",
   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.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.
+Run the CLI exactly as written here, `npx -y juicyjuicy@0.11.2 …`: 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.1 whoami --json
+npx -y juicyjuicy@0.11.2 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.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.
+- Run `npx -y juicyjuicy@0.11.2 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.1 init --yes --json \
+npx -y juicyjuicy@0.11.2 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.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.
+1. **Check.** Run `npx -y juicyjuicy@0.11.2 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.1 publish --json --message "<what changed, in a few words>"
+npx -y juicyjuicy@0.11.2 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.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).
+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.2 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.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.
+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.2 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.1 remix <slug> --json
+npx -y juicyjuicy@0.11.2 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.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.
+- `npx -y juicyjuicy@0.11.2 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.2 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.2 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.2 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.2 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.2 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.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.
+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.2 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

@@ -501,11 +501,12 @@ Every game gets this multiplayer menu unless the user asks for another. Build it
 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`).
+   - The players, the host marked (a crown or "(host)"), and one "Waiting for players… 2/4" row while there's room (`room.max`).
+   - For the host only, a **kick button** (×, with `aria-label="Kick <name>"`) on every other player's row: `room.kick(id)` removes them for good (they can't rejoin this lobby and don't see it in Search). If the game shows the players during play (a top bar, a pause menu), the host gets the same button there.
    - **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.
+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 (`KICKED`: "You were removed from the lobby").
 
 ## Using it
 ```js
@@ -545,6 +546,7 @@ function start(room) {
   leaveButton.onclick = () => room.leave();
   room.on("join", () => showLobby(room));
   room.on("leave", () => showLobby(room));
+  // In showLobby, the host's row for each other player gets a × button: () => room.kick(player.id)
   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)));

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.1 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.2 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.1 check-games --json
+   npx -y juicyjuicy@0.11.2 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.1 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.2 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.1",
+  "version": "0.11.2",
   "description": "Publish AI-made browser games to juicyjuicy.games",
   "type": "module",
   "license": "MIT",