summer-engine 3.5.1 → 3.5.2

package/library/skills/multiplayer-publish/SKILL.md

@@ -96,6 +96,15 @@ To make the same in the Export dialog:
 Both presets must include the composition; each must include its entry
 scene.
 
+The `summer_authority` custom feature is what makes the server start the
+authority. Summer starts `server.pck` with no scene argument, so the pack's
+own main scene decides what runs: `run/main_scene.summer_authority` from
+`project.godot` (`multiplayer-project`), which applies only to a pack whose
+preset carries that feature. Without it, the server runs the client's main
+scene, usually the title. It never restores the World or reports ready, and
+every online join fails with `world_start_timeout`. Local Play and the upload
+checks name the scene themselves, so they can't catch this; step 4d can.
+
 Textures: iOS and macOS read ETC2/ASTC (`textures/vram_compression/import_etc2_astc=true`
 in `project.godot`), and Windows reads S3TC/BPTC (`import_s3tc_bptc=true`).
 Enable the ones for the platforms you tick. The exporter's **Fix Import**
@@ -126,13 +135,22 @@ summer.games: Publish uploads this one file as a new Build.
 ```
 
 Check that `server.pck` and your `config/` files are listed, and that the
-"Left N server-only files" count covers your `authority/` files. Every
+"Left N server-only files" count covers your `authority/` files. The
+`Server: … mainScene …` line names the scene the Build declares, not the
+scene the pack will start; step 4d checks that. The `Exported by Summer`
+line must name a released Summer: export with the released editor from the
+download page, never a development build, and export again after you update
+Summer. Players' apps run the packs on the released Summer of that version;
+step 4e checks it. Every
 result message and every export error, with its fix, is in
 [export-errors.md](export-errors.md).
 
 ## 4. Check before uploading
 
-Do all three. Each catches problems the export doesn't.
+Do all five. Each catches problems the export doesn't. Run them on the
+`.zip` you will upload, not on a pack exported separately with the server
+preset (`--export-pack`): that pack differs from the bundle's `server.pck`,
+for example it keeps `gameId`, and can pass where the upload fails.
 
 **a. Local Play passes** (`multiplayer-testing`): every process has
 `script_errors` 0, there's no `cannot attach`, and your ready lines appear.
@@ -187,12 +205,45 @@ unzip -o build/courtyard.summer.zip client.pck server.pck -d "$P/out"
 Paths must be absolute. Pass: both reports say `"sceneLoaded": true`, and
 their `compositionManifest` objects are identical. On failure the probe
 writes `rejection.json`; its codes are in [export-errors.md](export-errors.md).
+The probe names the scene to load, so it does not show which scene the
+server starts on its own.
+
+**d. The server pack starts the authority scene.** Start the bundle's
+`server.pck` the way Summer does, with no scene argument, and stop it after
+a few seconds:
+
+```sh
+perl -e 'alarm shift; exec @ARGV' 15 <summer> --headless --verbose --main-pack "$P/out/server.pck"
+```
+
+The first `Completed load for: 'res://….tscn'` line must be the authority
+scene (`res://authority/main.tscn` here). If it is the client or title
+scene, add `summer_authority` to the server preset's custom features and
+export again. Later lines may complain that there is no hosted World; that
+is expected locally.
+
+**e. The client compiles on the released Summer.** Run the bundle's
+`client.pck` with the released Summer of the version the export names (see
+`release-readiness` check 7 for how to confirm the stamp), and fail on any
+compile error:
+
+```sh
+perl -e 'alarm shift; exec @ARGV' 60 <released-summer> --headless --verbose --main-pack "$P/out/client.pck" --quit-after 600 > "$P/out/client-run.log" 2>&1
+grep -E 'SCRIPT ERROR|Parse Error|Failed to load script' "$P/out/client-run.log"
+```
+
+The grep must print nothing; the run itself exits normally even when a
+script fails. A failure here, such as `Static function "party_queue()" not
+found`, means the scripts use an API the released version lacks, usually
+because a development build made the export. Every player would see an
+empty window. Re-export with the current Summer release.
 
 ## 5. Upload the Build
 
 1. The game must exist in Summer Studio, and `gameId` in
-   `summer.build.json` and `GAME_ID` in `network/game.gd` must both be its
-   id.
+   `summer.build.json` must be its id. The export leaves `gameId` out of the
+   bundle, and the game code calls `Summer.initialize()` with no ID: a
+   literal or fallback ID fails hosted with `game_identity_mismatch`.
 2. Open the game's Builds page: `summer_open` with target `game`,
    `gameId` and section `builds`, or summerengine.com → Studio → your game →
    Builds.
@@ -209,6 +260,28 @@ writes `rejection.json`; its codes are in [export-errors.md](export-errors.md).
 For a client-only fix to an existing Build, export to a `.pck` path instead
 of `.zip`. That writes `client.pck` alone.
 
+## 6. Join it for real
+
+Right after the Build is released, open the game in a Summer Games app,
+join online and play until you are in the game, before players hear about
+the update. A wrong Game ID only fails under a real hosted launch, so
+nothing before this step catches it. An agent can't do this; ask the user
+and record the result. The whole list of checks before a release is
+`release-readiness`, and the creator docs have it at
+https://docs.summerengine.com/publishing/release-readiness.
+
+## When online joins fail
+
+Every join ends in `world_start_timeout`, but Local Play works:
+
+1. The server starts the wrong scene: run step 4d.
+2. The game passes a fixed Game ID to `Summer.initialize`: pass none.
+
+Then export, upload and release a new Build, and join again. An empty game
+server log is not proof that the server hung: a release server holds back
+what the game prints until it exits when it isn't attached to a terminal.
+Use step 4d to see which scene runs.
+
 ## Checklist
 
 - [ ] `summer.build.json`: `gameId`, `targetPlatforms`, `server.exportPreset`, every WorldDefinition selected by a queue.
@@ -217,6 +290,10 @@ of `.zip`. That writes `client.pck` alone.
 - [ ] The export ends with `Publish uploads this one file as a new Build.`
 - [ ] The analyzer prints `ok=true` twice.
 - [ ] Both probes load their scene, with identical composition manifests.
+- [ ] The bundle's `server.pck`, run with no scene, loads the authority scene first.
+- [ ] `Exported by Summer` names a released Summer, and the bundle's `client.pck` run on that release prints no `SCRIPT ERROR`, `Parse Error` or `Failed to load script`.
+- [ ] Every `Summer.initialize` call passes no Game ID.
+- [ ] After release: a real online join reaches the game (`release-readiness`).
 - [ ] Local Play passed with the same project.
 
 ## Common mistakes
@@ -229,5 +306,9 @@ of `.zip`. That writes `client.pck` alone.
 | Ship C#, `.gdextension` or native libraries in the client | GDScript only | Summer Games runs GDScript client packs only |
 | Skip the source graph | Keep `source-domains.json` complete | Without it the server code ships to players (export warns) |
 | Load an `authority/` file from client code | Move shared code into `network/` | The export stops: the client would load a missing file |
-| Upload after only exporting | Run Local Play, the analyzer and both probes first | Each catches what the others miss |
+| Upload after only exporting | Run Local Play, the analyzer, both probes and the server start check first | Each catches what the others miss |
+| Server preset without the `summer_authority` feature | `custom_features="summer_authority"` | The hosted server starts the title and every join times out |
+| Test a server pack exported on its own | Test the `server.pck` inside the `.zip` | The separate pack keeps `gameId` and hides a wrong Game ID |
+| Export with a development build of Summer | Export with the released editor from the download page, again after every update | Players run the pack on the released Summer of the stamped version; newer APIs fail to compile and the game opens to an empty window |
+| Read an empty server log as a hang | Run step 4d | A release server holds back its output until it exits |
 | Export a patch | Export Project, or Export PCK/ZIP without Export As Patch | summer.games takes complete bundles or packs |

package/library/skills/multiplayer-publish/resource.yaml

@@ -22,6 +22,7 @@ related:
     - skill/multiplayer
     - skill/multiplayer-project
     - skill/multiplayer-testing
+    - skill/release-readiness
 source: official
 license: MIT
 status: preview

package/library/skills/multiplayer-state/SKILL.md

@@ -174,7 +174,7 @@ func _ready() -> void:
 	spawner.entity_spawned.connect(_on_player_spawned)
 	spawner.command_received.connect(_on_command)
 	world.session_left.connect(_on_session_left)
-	var initialized: SummerResult = await Summer.initialize(Game.GAME_ID).get_result_or_completed_signal()
+	var initialized: SummerResult = await Summer.initialize().get_result_or_completed_signal()
 	if not initialized.ok:
 		push_error(initialized.message)
 		return

package/library/skills/multiplayer-state/files.md

@@ -33,7 +33,7 @@ func _ready() -> void:
 	spawner.entity_spawned.connect(_on_player_spawned)
 	spawner.command_received.connect(_on_command)
 	world.session_left.connect(_on_session_left)
-	var initialized: SummerResult = await Summer.initialize(Game.GAME_ID).get_result_or_completed_signal()
+	var initialized: SummerResult = await Summer.initialize().get_result_or_completed_signal()
 	if not initialized.ok:
 		push_error(initialized.message)
 		return
@@ -266,7 +266,7 @@ func _ready() -> void:
 	spawner.state_group_created.connect(_on_group_created)
 	spawner.entity_spawned.connect(_on_entity_spawned)
 	spawner.event_received.connect(_on_event)
-	var initialized: SummerResult = await Summer.initialize(Game.GAME_ID).get_result_or_completed_signal()
+	var initialized: SummerResult = await Summer.initialize().get_result_or_completed_signal()
 	if not initialized.ok:
 		push_error(initialized.message)
 		return
@@ -528,7 +528,6 @@ occurrence_streams = Array[SummerNetworkOccurrenceStream]([SubResource("Commands
 extends RefCounted
 ## Shared by the client and the authority: ids, streams and shared rules.
 
-const GAME_ID := "game_courtyard"
 const QUEUE := &"courtyard"
 const MOTION := &"courtyard.motion"
 const CMD := &"courtyard.cmd"

package/library/skills/multiplayer-testing/SKILL.md

@@ -207,9 +207,22 @@ capture, window size) with `DisplayServer.get_name() != "headless"`.
   `Summer.client.leave()` only disconnects. `session_disconnected` fires and
   their seat is held. `session_left` arrives when the World ends; hosted, it
   arrives when Summer ends the Session.
+- **Which scene the hosted server starts.** Local Play starts the authority
+  scene by name. Summer starts the exported `server.pck` with no scene, so a
+  server preset without the `summer_authority` feature still passes here and
+  then runs the title screen hosted, where every join fails with
+  `world_start_timeout`. Run the bundle's `server.pck` with no scene
+  (`multiplayer-publish`, step 4d).
+- **A wrong Game ID.** Local Play has no hosted identity, so
+  `Summer.initialize("some-id")` passes here and fails hosted with
+  `game_identity_mismatch`. Call `Summer.initialize()` with no ID; only a
+  real online join after publishing proves it.
 - **Real devices, real accounts, real distances.** Publish to staging for that
   (`multiplayer-publish`).
 
+Before a version reaches players, run `release-readiness`: it covers these
+gaps on the `.zip` you upload.
+
 ## Checklist for any multiplayer change
 
 - [ ] Ran Local Play with at least 2 players, and once with 100 ms / 10 ms / 1 %.

package/library/skills/multiplayer-testing/resource.yaml

@@ -26,6 +26,7 @@ related:
     - skill/multiplayer-movement
     - skill/multiplayer-state
     - skill/multiplayer-publish
+    - skill/release-readiness
     - skill/summer-friends
     - skill/summer-match-results
     - skill/summer-matchmaking

package/library/skills/publish-your-game/SKILL.md

@@ -18,4 +18,6 @@ Its current text lives on the hosted Summer Engine MCP, the same text the Studio
 2. A host that shows MCP prompts or resources has it as the `publish-your-game` prompt and the resource `summer://skills/publish-your-game`.
 3. Without a store sign-in: https://docs.summerengine.com/llms.txt lists every docs page; fetch any page as .md.
 
+Before the build upload, run `release-readiness` on the exact `.zip` you upload, and report each check to the owner; a hosted game's upload checks can pass while every online join fails.
+
 The one rule to keep even before you load it: Submitting does not publish. `summer_store_submit` returns an approval link; only the owner's click sends the game to review, and review comes before live.

package/library/skills/release-readiness/SKILL.md

@@ -0,0 +1,298 @@
+---
+name: release-readiness
+description: "Before releasing a Summer game version, prove players can play it: server scene, online join, saved progress, no fixed Game ID, a released Summer compiles it."
+license: MIT
+compatibility: [Cursor, Claude Code, Windsurf, Codex]
+category: deployment
+user-invocable: true
+allowed-tools: Read Grep Glob Bash summer_read_file summer_get_diagnostics
+paths: ["export_presets.cfg", "project.godot", "summer.build.json", "world.json", "**/*.gd"]
+---
+
+# /release-readiness: prove players can play it
+
+Summer checks every upload: platforms, packs, and the files they name. Those
+checks prove the export is well formed. They can't prove that a player who
+presses **Play online** gets into a game. Each check below exists because a
+real release passed every upload check and still failed for its players.
+
+The creator docs have the same checklist, with the same numbers:
+https://docs.summerengine.com/publishing/release-readiness (fetch it as `.md`).
+
+## When to run it
+
+- Before you upload a new Build of a game that will go to players.
+- Before you promote or release a version.
+- After a release fails for players, to find the cause, and then to add the
+  check that would have caught it (see the last section).
+
+For a jam build or a prototype nobody else plays, skip it.
+
+## How to report
+
+Run every check that applies. Each check needs **evidence**: a command's
+output or something you saw in the running game. Reading the project and
+deciding it looks right is not evidence.
+
+Report one line per check:
+
+- **pass**, with the evidence;
+- **fail**, with what you saw;
+- **not applicable**, with the reason (for example, no server);
+- **not run**, with what is still needed (for example, "needs a real online
+  join after publishing").
+
+A check that was not run is not a pass. Show the list to the user before you
+change anything; the user decides what to fix and whether to release with a
+check still open.
+
+## Test the file you upload
+
+Run the checks on the summer.games `.zip`, not on something close to it.
+Export the bundle (in the editor: **Project > Export**, preset
+**summer.games**, **Export Project**; from an agent: `summer_export_game`; or
+from a terminal), then take the server pack and the packaged build file out
+of it:
+
+```sh
+<summer> --headless --path . --import
+<summer> --headless --path . --export-release "summer.games" build/<game>.summer.zip
+mkdir -p build/bundle
+unzip -o build/<game>.summer.zip server.pck client.pck summer-bundle.json config/summer.build.json -d build/bundle
+```
+
+A game without a server has no `server.pck` or `config/`; `unzip` then
+warns about the missing names and extracts the rest.
+
+`<summer>` is the Summer Engine executable. Two look-alikes hide real
+failures:
+
+- **A server pack exported on its own** with your server preset
+  (`--export-pack`) is not the bundle's `server.pck`. For example, it keeps
+  `gameId`, which the bundle leaves out, so it can pass check 6 while the
+  uploaded `.zip` fails it.
+- **Local Play** always starts the authority scene by name, so it can't catch
+  check 1. It also runs without a hosted identity, so it can't catch check 6.
+
+## The checks
+
+Checks 1 and 2 apply to every game with a server (`summer.build.json` names
+a `server.exportPreset`). Checks 3 and 4 apply to every game with online
+play. Checks 5, 6 and 7 apply to every game.
+
+### 1. The server pack starts the authority scene
+
+**Why.** Summer starts a hosted World's `server.pck` with no scene argument,
+so the pack's own main scene decides what runs. The server preset must carry
+the custom feature `summer_authority`, and `project.godot` must set that
+feature's main scene:
+
+```ini
+[application]
+
+run/main_scene="res://client/main.tscn"
+run/main_scene.summer_client="res://client/main.tscn"
+run/main_scene.summer_authority="res://authority/main.tscn"
+```
+
+```ini
+# export_presets.cfg, the server preset
+platform="Linux"
+dedicated_server=true
+custom_features="summer_authority"
+```
+
+Without the feature, `run/main_scene.summer_authority` never applies and
+the server starts the players' main scene, usually the title screen. That
+scene never restores the World or tells Summer it is ready, so **every
+online join fails with `world_start_timeout`**. The bundle manifest still
+names the authority scene as the server's main scene, so reading the
+manifest proves nothing.
+
+**Check it.** Start the bundle's `server.pck` the way Summer does, with no
+scene argument, and stop it after a few seconds:
+
+```sh
+perl -e 'alarm shift; exec @ARGV' 15 <summer> --headless --verbose --main-pack build/bundle/server.pck
+```
+
+Find the first `Completed load for: 'res://….tscn'` line. It must be the
+authority scene: the `entry_point` of the `headless_engine` component in
+`world.json`. Later lines may complain that there is no hosted World; that
+is expected in a local run. Then confirm the source too: the server preset in
+`export_presets.cfg` has `summer_authority` in `custom_features`, and
+`project.godot` sets `run/main_scene.summer_authority`.
+
+**Fix.** Add `summer_authority` to the server preset's **Features > Custom**,
+set `application/run/main_scene.summer_authority` to the authority scene,
+export again and rerun the check. If your Summer version's export refuses a
+server pack that starts the wrong scene, that refusal is this check failing;
+run the check anyway, because older versions don't refuse it.
+
+### 2. Join online with the version you release
+
+**Why.** Check 1 runs on your computer. Players use a hosted server, and some
+failures, such as check 6, only show up there.
+
+**Check it.** Right after you publish or promote the version, open the game
+in a Summer Games app as a player, join online and play until you are in the
+game. Do it before you tell players about the update. An agent can't do this
+step; report it as **not run** and ask the user to do it, then record what
+they saw. If the join fails, see [Troubleshooting](#troubleshooting).
+
+### 3. Players can find online play
+
+**Why.** If nobody, including you, reaches online play, nobody notices when
+it breaks. A game hid online play behind a grown-ups setting, so its hosted
+join was never tried before release, and it failed for every player who
+found it.
+
+**Check it.** Start the client as a new player and follow the default path
+to online play. List every gate on that path: settings, parental or age
+gates, debug toggles. A new player should reach online play without
+changing a setting. If online play is off by default on purpose, the user
+must confirm that decision, and then check 2 must run before every release.
+
+### 4. The server saves online progress
+
+**Why.** Progress kept only in the player's local files is lost on
+reinstall or a new device, and players can edit it.
+
+**Check it.** In code, the authority loads each player's progress when they
+join (`Summer.authority.player_data.load(session)`) and saves it with
+`commit_public` or `commit_secret` (`summer-player-data`). Then play online,
+earn something, leave, and join again from a fresh install or another
+device. The progress must still be there. Local Play stores player data on
+disk; only hosted play proves it lasts.
+
+### 5. Players can get back to the title
+
+**Why.** A player with no way out of a session has to kill the app.
+
+**Check it.** Play into a session, online and offline, and find the way
+back: a pause menu or a **Leave** button. Use it, then start a new session
+from the title. In online play, leaving should call
+`Summer.client.leave()` before the title loads.
+
+### 6. The game doesn't hard-code its Game ID
+
+**Why.** The summer.games export is portable: the bundle's
+`summer.build.json` has no `gameId`. Summer takes the game's identity from
+wherever it runs: the Summer Games app, the hosted server or Local Play.
+Any other ID fails on the hosted server with `game_identity_mismatch`, "The
+initialized Game ID does not match hosted runtime context." The authority
+then stops before it restores the World or reports ready, and every online
+join ends in `world_start_timeout`, even though check 1 passes. The Summer
+Games app refuses a mismatched ID the same way.
+
+**Check it.**
+
+1. Find every call: `grep -rn "Summer.initialize" --include=*.gd .`
+2. For each, trace the argument back to where it comes from. It must be
+   nothing (`Summer.initialize()`) or an ID the game got from Summer. It must
+   never be a literal, a placeholder, or a fallback such as
+   `"game.my-game"` used when `gameId` is missing.
+3. `cat build/bundle/config/summer.build.json`: it has no `gameId`, so
+   anything the game reads from this file at run time comes back empty.
+
+Local Play and the local run in check 1 have no hosted identity, so a wrong
+ID passes there. Only check 2 proves this one.
+
+**Fix.** Call `Summer.initialize()` with no ID (Summer 0.7.1 and later), on
+the client and on the authority.
+
+### 7. Export with a released Summer, and its scripts compile on the players' runtime
+
+**Why.** The export records which Summer made it, in the client pack's
+`.summer/export.json` and under `export` in the bundle's
+`summer-bundle.json`: `summerVersion` and `engineSha`. Players' apps run the
+game on a released Summer runtime with the same MAJOR.MINOR and a patch at
+least the stamped one. A development build of Summer
+can stamp a version that is already released while it has APIs that release
+lacks. Scripts that use them then fail to compile on every player's device,
+and the game opens to an empty or black window. Summer doesn't compile
+scripts when you upload, so every upload check passes.
+
+**Check it.**
+
+1. Read the stamp: `cat build/bundle/summer-bundle.json`. The export log
+   shows it too: `Exported by Summer <version> (engine <sha>)`.
+2. `summerVersion` must be a released Summer version, and `engineSha` must
+   equal that release's `engineSha` in
+   `downloads.summer.games/engine-templates/<summerVersion>/manifest.json`
+   (published for Summer 0.7.1 and later). If it differs, or that address has
+   nothing for the version, a development build made the export.
+3. Run the client pack on that released Summer, and fail on any compile
+   error. The run exits normally even when a script fails, so the grep is the
+   check:
+
+   ```sh
+   perl -e 'alarm shift; exec @ARGV' 60 <released-summer> --headless --verbose --main-pack build/bundle/client.pck --quit-after 600 > build/client-run.log 2>&1
+   grep -E 'SCRIPT ERROR|Parse Error|Failed to load script' build/client-run.log
+   ```
+
+   `<released-summer>` is the Summer executable of the stamped version from
+   the download page, not the development build that made the export. The
+   grep must print nothing. The run compiles the scripts that the main
+   scene and autoloads load; a script that loads only later in play compiles
+   when play reaches it, so check 2 still matters for online games.
+
+**Fix.** Ask the user to install the current Summer release from
+https://summerengine.com/download (or, with their OK, run
+`summer install --yes`). Export again with it, and rerun this check on the
+new `.zip` before you upload it.
+
+## Troubleshooting
+
+### Every online join fails with `world_start_timeout`, but Local Play works
+
+Most likely, in this order:
+
+1. The server pack starts the wrong scene. Run check 1.
+2. The game passes a fixed Game ID. Run check 6.
+
+After the fix, export a new `.zip`, upload it, promote it and run check 2.
+
+### The game opens to a blank window for every player
+
+The game works in your editor, but every player sees an empty or black
+window. Running the client pack as in check 7 prints
+`Parse Error: Static function "…" not found` and
+`Failed to load script "res://…"`. A development build of Summer made the
+export, and the scripts use something the released version doesn't have.
+Re-export with the current Summer release, upload the new version and
+promote it.
+
+### The game server's log is empty
+
+An empty server log is not proof that the server hung or never started. A
+release server holds back what the game prints until it exits when it isn't
+attached to a terminal, so its log can look empty while the title scene
+runs. Don't debug from the empty log; run check 1 on your own computer to
+see which scene starts.
+
+## Add a check after every incident
+
+The list grows from real failures. When a release fails in a way no check
+here would have caught:
+
+1. Fix the game, and record the cause in the project's `.summer/memory/`.
+2. Write the check that would have caught it: **Why**, **Check it** (a
+   command to run or something to observe, against the real summer.games
+   `.zip`), and **Fix**.
+3. Propose it for this skill and for the docs page
+   (`/publishing/release-readiness`), with the same number in both, through
+   a pull request to summerengine/summer and to the docs. Until it lands,
+   keep it in the project's memory so the next release runs it.
+
+## Checklist
+
+- [ ] Ran the checks on the summer.games `.zip` you upload, not a separately exported pack.
+- [ ] 1. The bundle's `server.pck`, run with no scene, loads the authority scene first.
+- [ ] 2. A real online join with the released version reaches the game (or is reported as not run).
+- [ ] 3. A new player reaches online play without changing a setting, or the user confirmed it is off on purpose.
+- [ ] 4. Online progress is loaded and committed through authority player data, and survives a fresh install.
+- [ ] 5. Players can get back to the title from inside a session, online and offline.
+- [ ] 6. Every `Summer.initialize` passes no ID, or an ID the game got from Summer.
+- [ ] 7. The export stamp names a released Summer and its `engineSha`, and `client.pck` run on that released Summer prints no `SCRIPT ERROR`, `Parse Error` or `Failed to load script`.
+- [ ] One line per check reported to the user before anything is changed.

package/library/skills/release-readiness/resource.yaml

@@ -0,0 +1,41 @@
+id: skill/release-readiness
+kind: skill
+version: 1.0.0
+summary: "Before releasing a Summer game version, prove players can play it: server scene, online join, saved progress, no fixed Game ID, a released Summer compiles it."
+use_when:
+  - "before uploading, promoting or releasing a new version to players: is it ready to release"
+  - "every online join fails with world_start_timeout, or the hosted server's log is empty, while Local Play works"
+  - "Summer.initialize fails with game_identity_mismatch: the initialized Game ID does not match hosted runtime context"
+  - "checking that a hosted game's server.pck starts the authority scene and not the title screen"
+  - "players get a blank or black screen when they open the released game, but it runs in the editor: client scripts fail with Parse Error or Failed to load script"
+  - "a game release failed for players and the check that would have caught it needs adding"
+do_not_use_when:
+  - "only producing a local export for a jam or prototype nobody else plays — skill/export-and-ship"
+facets:
+  lifecycle:
+    - launch
+    - support
+  domains:
+    - deployment
+    - multiplayer
+    - playtest
+  modalities:
+    - project
+    - docs
+compatibility:
+  engine: ">=4.6"
+related:
+  skills:
+    - skill/multiplayer
+    - skill/multiplayer-publish
+    - skill/multiplayer-testing
+    - skill/multiplayer-project
+    - skill/summer-player-data
+    - skill/publish-your-game
+    - skill/export-and-ship
+    - skill/make-game
+    - skill/bounded-engine-runs
+source: official
+license: MIT
+status: preview
+recommended: false

package/library/skills/summer-parties/SKILL.md

@@ -57,7 +57,7 @@ func _ready() -> void:
 	spawner.state_group_created.connect(_on_group_created)
 	spawner.entity_spawned.connect(_on_entity_spawned)
 	spawner.event_received.connect(_on_event)
-	var initialized: SummerResult = await Summer.initialize(Game.GAME_ID).get_result_or_completed_signal()
+	var initialized: SummerResult = await Summer.initialize().get_result_or_completed_signal()
 	if not initialized.ok:
 		push_error(initialized.message)
 		return

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "summer-engine",
-  "version": "3.5.1",
+  "version": "3.5.2",
   "description": "Local Summer CLI and MCP server for Summer Engine. Install and run the engine, connect Claude Code, Cursor, Codex, Gemini, and other agents, and build real games with bundled skills, hooks, and plugins.",
   "keywords": [
     "summer-engine",

package/registry/generated/counts.json

@@ -4,9 +4,9 @@
     "collection": 0,
     "example": 0,
     "reference": 9,
-    "skill": 122,
+    "skill": 123,
     "template": 19,
     "tool": 105
   },
-  "total": 255
+  "total": 256
 }

package/registry/generated/gemini-extension.json

@@ -1,7 +1,7 @@
 {
   "_generated": "GENERATED from integrations/gemini — do not edit; npm run generate:registry",
   "name": "summer",
-  "version": "3.5.1",
+  "version": "3.5.2",
   "description": "Agent tooling for Summer Engine: MCP bridge, context primer, and game-dev skills. Use with the npm CLI for skill files on disk.",
   "contextFileName": "GEMINI.md",
   "mcpServers": {
@@ -93,6 +93,7 @@
     "./library/skills/psx-retro-rendering/",
     "./library/skills/publish-your-game/",
     "./library/skills/realtime-wet-surfaces/",
+    "./library/skills/release-readiness/",
     "./library/skills/remote-deploy/",
     "./library/skills/retarget/",
     "./library/skills/running-in-the-cloud/",