summer-engine 3.8.0 → 4.2.0

package/CHANGELOG.md

@@ -2,6 +2,139 @@
 
 All notable changes to summer-engine will be documented here. Following [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) and [Semantic Versioning](https://semver.org/).
 
+## [4.2.0] - 2026-10-16
+
+4.1.0 was not published to npm. 4.2.0 is the first release with everything in it (the [4.1.0] section below), plus these changes.
+
+Upgrades keep agents current: the installed Summer skills refresh themselves after an upgrade, every Summer project gets an AGENTS.md, the CLI path can let Claude Code and Codex run read-only commands without asking, and Gemini CLI installs come with the skills.
+
+- **The CLI path can ask less.** `summer setup claude-code --cli --allow-rules --yes` lets Claude Code run read-only and dry-run `summer` commands without asking: a reviewed list of reads (`summer ops search`, `summer jobs wait`, `summer engine screenshot`, ...; `jobs wait` and `assets get` also save the files they name) and every spend only as a dry run (`summer assets generate-image --dry-run ...`, the flag right after the action). It is opt-in: the flag is in the command the person approves, setup prints every rule, and without `--yes` it writes nothing. The rules, for both `summer` and `npx -y summer-engine@latest`, go into `permissions.allow` in `~/.claude/settings.json` (`.claude/settings.local.json` with `--scope project`); nothing else in the file changes. `summer setup codex --cli --allow-rules --yes` writes the same as Summer's own Codex rules file, `~/.codex/rules/summer.rules`. `--remove-allow-rules` takes exactly these rules out again. Changes, publishing, prices, deletes, messages and `engine capture-gameplay` (it runs the project's own code) still ask. A call with `--dry-run` is now a dry run whatever its input says (`--no-dry-run` or `"dryRun": false` in `--input` no longer undo it).
+- **Devin Desktop (formerly Windsurf): the MCP config moved** to `~/.config/devin/mcp_config.json` (`$XDG_CONFIG_HOME/devin`, Windows `%APPDATA%\devin`), per Devin's docs. `summer setup windsurf` writes it there and says when an earlier setup's entry is still in `~/.codeium/windsurf/mcp_config.json` (left as it is for older builds).
+- **Gemini CLI extensions get the skills.** `gemini extensions install https://github.com/SummerEngine/summer` and the Gemini CLI gallery install a release's only asset, and each GitHub Release now carries one: `summer-gemini-extension.tar.gz`, the extension with `skills/<slug>/` for every bundled skill (Gemini reads skills only from that folder; the repository keeps them in `library/skills/`). A clone of the repository gave no skills.
+- **A Claude plugin for Anthropic's plugin directory** in `plugins/claude/`: the same plugin from a folder of its own (292 files, under the directory's 512), with the server and every `summer-engine@latest` pinned to this version. `npm run generate:registry` writes it, `--check` fails when it drifts, and `claude plugin validate --strict plugins/claude` passes.
+- **Every Summer project has an AGENTS.md.** `summer create` writes a short AGENTS.md, the one file Codex, Cursor, Copilot, Amp and other agents read in every session: this is a Summer Engine game in GDScript, how to work on it with the MCP tools or the `summer` CLI, where Summer's skills are, the five most useful commands, and that publishing needs the owner's approval. It also writes a CLAUDE.md that only holds `@AGENTS.md`, for Claude Code. `summer setup --yes` run inside a project adds both when they are missing (without `--yes` it says what it would add; `--no-project-files` and `--assets-only` leave the project alone). The project is the nearest folder with `project.godot` at or above the working directory, no higher than the git top level and never the home folder. An existing AGENTS.md or CLAUDE.md is never overwritten: setup adds one marked Summer block once and later updates only that block, in the file's own line endings. A CLAUDE.md that already imports AGENTS.md stays as it is, a CLAUDE.md that is a link to AGENTS.md (or the reverse) gets the AGENTS.md block once, a link to a missing file or out of the project is left alone, and a file setup cannot write is reported with the reason. The five commands come from the `summer-cli` skill, and a test runs every command both teach.
+- **Upgrades refresh the installed skills.** The first `summer mcp` start (v4 surface) after an upgrade brings the Summer skills already installed on the computer to the new version, then says so once: in the session's instructions, so the agent can tell the person, and on stderr. Before, skills from 3.x stayed until someone ran `summer setup --force`. While they stayed, the local server kept the legacy toolset on, and agents kept calling 3.x tools; that undid about half of 4.0's smaller tool list. Now the legacy toolset is off from that first start; 3.x tool names still run through `summer_call`, and `--toolsets legacy` or `SUMMER_LEGACY_TOOLS=on` lists them again.
+  - Only Summer's own copies are replaced: real folders (not links) whose `resource.yaml` names that skill, in a skills folder with Summer's version marker. A skill from another pack with the same name, and a Summer skill someone changed after install, stay as they are, at this and every later release until `summer setup --force` (the version marker lists them); the notice names them. A pre-release never takes a release's skills back. Nothing is removed. New library skills are added only to a folder that holds nearly the whole library, so an assets-only install stays one.
+  - Each skill is copied beside the old one and swapped in with renames, under a lock per folder, and the version marker is written last. A killed start or a copy error leaves the old skill, and the next start finishes. A refresh error never stops `summer mcp`; it goes to the MCP log.
+  - Rule-file installs (Cline, Roo Code, old Cursor rules) are not refreshed; `summer doctor` still prints the command for them.
+- **`summer_call` on the local server takes `name` as well as `op`.** Agents copied the `name` field that `summer_search` answers with and got an input error. When both are given and differ, it answers `invalid_input`.
+
+## [4.1.0] - 2026-10-16
+
+Not published to npm: these changes ship in 4.2.0.
+
+Summer without MCP: any agent runs Summer from its shell with the `summer` CLI and the `summer-cli` skill. Every operation is found without a sign-in, search understands plain English, and Summer installs with Homebrew.
+
+- **`--json` on every read command.** `summer ops describe <op> --json` failed with "unknown option '--json'"; it now prints the same answer as the other operation commands (`{ok, status, result: {operation}}`, warnings inside). `summer status`, `summer list templates|projects`, `summer skills list`, `summer skills info`, `summer memory show`, `summer memory path` and `summer config get` take `--json` too. A test lists every CLI command and fails when a read command has no `--json`. `summer tool` keeps printing JSON; its `--json` is still the old alias of `--args`.
+- **`summer setup <agent> --cli`: Summer without MCP.** Installs the skills for the agent and writes no MCP entry and no Summer Games entry. The agent runs Summer as `summer <area> <action>` commands in its shell. `--no-mcp` is the same. With `--assets-only` it installs only the asset skills. Claude Code gets no slash commands (`/summer`, `/gameskill`, `/start` start work through the MCP tools; `summer skills install --no-commands` leaves them out too). An existing `summer-engine` entry from an earlier setup stays, and setup says so: a stdio or URL entry, and Claude Code's per-project ones. `--print`, `--profile`, `--local-dev` and `--channel` shape only the MCP entry, so `--cli` refuses them. It also refuses agents without a skills folder, Gemini CLI (its skills load only through its extension, which runs the MCP server) and Roo Code (its skills are rule files that tell it to use the MCP tools). When an agent's config lists no `summer-engine` and `--cli` can set the agent up, the skills refresh `summer doctor` recommends adds `--cli`, so it adds no MCP server.
+- **New skill `summer-cli`** (preview): sign in, find an operation (`summer ops search`, `summer ops describe`), run it (`--input`, `--dry-run`, `--json`, `--idempotency-key`), long jobs (`--wait`, `summer jobs wait`), approvals, saving files (`--out`), the engine, and the next step for each error code. It checks `summer --version` first and uses `npx -y summer-engine@latest` when `summer` is missing or older than 4.0. A test dry-runs every command it teaches, offline. `using-summer` sends sessions without `summer_*` tools to it.
+- **Each skill shows the command for every tool it names.** A skill that names an MCP tool or an operation ends with a generated "From a shell" table: `summer_play` is `summer engine play`, `assets.generate_image` is `summer assets generate-image`, a split 3.x tool lists each operation, a merged one keeps the input it fixes (`summer_list_my_assets` is `summer assets search --scope mine`), and a merged one that runs here runs as itself (`summer_get_agent_playbook` is `summer tool get-agent-playbook`). `npm run generate:registry` writes it from the operation catalog. `validate:library` fails when it is stale, and when a skill names a 4.0 tool whose operation the catalog does not have. Tests check that every command names an operation this package runs or the catalog knows, and run the rows with a fixed input that run here, offline. `.gitattributes` keeps Markdown LF, so the check also holds on Windows checkouts. MCP tool names do not change.
+- **README: CLI only** (summer-engine 4.1.0 or newer), next to the hosted MCP block.
+- `summer <area> <action> --max-characters <n>` on a local read (`summer docs read`, the engine reads) no longer fails with an unknown key: the CLI prints the whole answer and says so.
+- Shorter descriptions for `summer-cli`, `summer-assets` and `concept-to-level`, so the installed skill descriptions leave room under the 12,000-character budget.
+- **Every operation is found without a sign-in.** `summer ops search`, `summer ops describe` and `summer_search` list every cloud operation (`store.publish`, `pricing.set_base`, ...) signed out, from the hosted server's public catalog shipped in the package (`registry/operations/public-catalog.json`). A cloud operation found signed out says `(needs sign-in)` (`needsSignIn: true` in JSON) and runs after `summer login`. Signed in, the server's live rows replace the shipped ones. `ops describe` of a cloud operation answers from the shipped catalog when the server cannot. `npm run sync:catalog` refreshes the copy; `npm run sync:catalog -- --check` runs before each release, and a test fails when the copy and `legacy-names.json` disagree.
+- **Search understands plain English.** "publish my game" finds `store.publish` first, "how did my game do" `analytics.summary`, "lower my price" `pricing.set_base`, "invite a teammate" `team.invite`, "take a screenshot" `engine.screenshot`, and "add multiplayer" the library search (the CLI prints the `summer docs search` command for it). Rare words weigh more and everyday verbs less, an operation whose title or tag the query says nearly word for word wins, and plain words reach the catalog's words (picture is image, music is audio). Local and cloud operations rank in one list, the same signed in or out. A test holds 35 real phrases.
+- **Install with Homebrew:** `brew install summerengine/tap/summer` (the SummerEngine/homebrew-tap formula follows npm `latest` by itself, checked every hour). The README starts with the three ways to install: the hosted URL for chat apps, Homebrew and npm.
+- `npm publish` no longer fails on a busy machine when it runs the tests again (`prepublishOnly`). Every test has a 20 s limit instead of 5 s, and the slow ones have their own: the first import of the built package (60 s), the template fetch timeout and the trajectory log rotation (30 s each), the `setup --cli` installs (120 s) and the app bundle export (60 s).
+- **`content` is an area.** `summer content <action>` runs the content operations Summer's hosted server serves (`content.list_games`, `content.get_kit`, `content.list_references`, `content.search_library`, `content.save_piece`, `content.add_feedback`, ...). The 4.0.0 `marketing.*` content operations are renamed to them (`marketing.content_feed` is `content.list_references`, `marketing.get_brand_pack` is `content.get_kit`); `registry/operations/legacy-names.json` maps each old name to its new one.
+- **Directory listings lead with "The game engine built for AI."** The MCP Registry entry (`server.json`) gets the Summer sun icon. The Codex plugin is named Summer Engine, with the short description "Make games with AI" (OpenAI allows 30 characters), a logo, a composer icon and a support link. The Cursor plugin is named Summer Engine and gets a logo. The Claude, Cursor, Codex, Factory and Gemini descriptions open with the product line. `glama.json` lets the maintainers claim the Glama listing. The README links support, privacy and terms.
+
+## [4.0.0] - 2026-10-15
+
+3.9.0 and 3.9.1 were not published to npm. 4.0.0 is the first release with everything in them (the [3.9.1] and [3.9.0] sections below), plus these changes.
+
+Summer 4.0: every Summer capability is one operation, named `area.action` (`assets.generate_image`, `store.publish`), with one answer shape, and `summer mcp` serves them by default. Engine tools keep their 3.x names. For everything else, `summer_search` finds the operation and its exact input, and `summer_call` runs it. The `summer` CLI runs the same operations.
+
+**To get the 3.x tools back:** start the server with `summer mcp --surface v3`, or add `SUMMER_SURFACE=v3` to the `env` of your agent's Summer MCP entry. That serves the 3.x tools as before. `SUMMER_SURFACE=v3` in your shell also leaves out the new `summer <area> <action>` commands.
+
+**If you signed in with 3.8.0 or earlier,** run `npx -y summer-engine@latest login` once. Generation and the other cloud operations now run on Summer's hosted server, which needs the store sign-in that `summer login` adds since 3.9.0.
+
+### What changes when you update
+
+- **3.x tool names keep working.** `summer_call` runs any 3.x tool by its old name, on the local server and on Summer's hosted server. While the Summer skills `summer setup` installed for your user are older than 4.0, `summer mcp` also lists every 3.x name again (the legacy toolset, local and hosted), each saying which operation replaces it and running as in 3.x. `--toolsets legacy` or `SUMMER_LEGACY_TOOLS=on` keeps them listed; `SUMMER_LEGACY_TOOLS=off` hides them. `npx -y summer-engine@latest setup <agent> --yes` installs the 4.0 skills. With skills from a plugin or a project folder, update them, or set `SUMMER_LEGACY_TOOLS=on` to keep the 3.x names listed.
+- **`summer mcp` serves the v4 surface by default** (`--surface v3` or `SUMMER_SURFACE=v3` brings back the 3.x tools). It lists the engine tools under their 3.x names, `summer_docs_search` and `summer_docs_read`, and two new tools: `summer_search` finds any operation, local or cloud, with its exact input, and `summer_call` runs it. Engine operations run here. Cloud operations run on Summer's hosted server, with the same approvals. Every 3.x tool can still be called through `summer_call`, by its old name too.
+- **One answer shape.** Every 4.0 tool answers `{ok, status, result}`: `done`, `running` with a job (`jobs.wait` waits up to 50 seconds per call), `needs_approval` with a link for the person, or `dry_run` with a preview. An error has a `code` (`engine_not_running`, `not_signed_in`, `no_credits`, `invalid_input`, ...), a message and exactly one `next` step. Every change takes `dryRun: true` (it changes and spends nothing) and an `idempotencyKey`, so a retry never runs twice.
+- **A failed cloud call says what happened.** `not_signed_in` only for a sign-in problem (a revoked or expired store sign-in says `npx -y summer-engine login --store --force`); `forbidden` when Summer refuses the account (for example an unconfirmed email). `unavailable` when nothing reached Summer's hosted server (no connection, the sign-in server down, a 503), or when a read or a dry run was cut off: it is safe to try again. `outcome_unknown` when a change was cut off after it was sent, because it may have run: call it again only with the same `idempotencyKey`, or check first. `--wait` keeps the job id when a wait does not get through. This holds for `summer_call`, the hosted direct tools and `summer <area> <action>`.
+- **Approvals.** A change that needs a person answers `needs_approval` with a link (`https://www.summerengine.com/studio/approvals/<id>`) and changes nothing until they approve; `jobs.wait` follows it to the end. Today that covers publishing a game (Summer Games asks the game's owner), price, sale and A/B test changes, member changes, deletes and anything that contacts people. Studio > Settings > Agent permissions lists the defaults; you can change them soon.
+- **`summer <area> <action> --field value`** (left out with `SUMMER_SURFACE=v3`). The CLI view of the same catalog, with `--dry-run`, `--wait` (follows a job or an approval to the end) and `--json`. It also adds `summer whoami`, `summer ops search <words>` and `summer ops describe <op>`.
+- **Generated files land on this machine again.** On the v4 surface and in the v4 CLI, `assets.generate_image`, `generate_audio`, `generate_3d`, `generate_video`, `generate_motion`, `assets.get` and `jobs.wait` take `out`: a folder or a file path (`res://` in a Godot project). The package keeps it (Summer's server never sees it), downloads each file the answer names and adds `localPath` beside its URL. 3D, video and animation save when `jobs.wait` sees the job finish, also after an approval. Without `out`, a generation in the assets profile or the CLI saves into the project's asset folder: Godot `assets/`, Unity `Assets/Summer`, Unreal `Content/Summer`, three.js `public/assets`. `assets.get` saves only with `out`, and sessions with engine tools save only with `out`, because `summer_import_asset_by_id` already puts the file in the project. A save never overwrites a file (it takes the next free name and says so), writes only media and model file types (never `.cs` or `.dll`), keeps `res://` inside the project, downloads only from public https hosts, up to 500 MB. Whatever is not saved is a warning; the answer stays as it was.
+- **The assets profile on 4.0.** `summer mcp --profile assets` (what `summer setup <agent> --assets-only` writes) lists Summer's hosted asset reads and generators, jobs and `whoami` as direct tools, plus `summer_search`, `summer_call` and the docs tools, and its instructions name only tools it lists. Generators run on Summer's hosted server by their 4.0 names; a 3.x generator name called through `summer_call` still runs the local 3.x tool.
+- **Skills use the 4.0 names.** The asset, publishing, plans, Summer Apps and Studio skills name the operations (`assets.generate_image`, `store.publish`, `plans.create`, `apps.call`, `studio.open`), every skill and reference names the docs tools `summer_docs_search` and `summer_docs_read`, and the asset skills save files with `out`. `validate:library` fails when a skill or reference names a 3.x docs tool. Engine tools keep their names.
+- **The docs describe 4.0.** README, AGENTS.md and `docs/` now say how to connect (one hosted URL and one sign-in for cloud work, the local server for engine work), how agents call Summer (operations, `summer_search` and `summer_call`, one answer shape and its error codes, 3.x names that keep working), what an agent may do on its own (Agent permissions, approvals, Agent activity), how credits and auto top-up work, the two store versions for ChatGPT and Claude's connector directory, and the `summer <area> <action>` CLI.
+- **`summer_run_script` takes `scenePath` and is stable.** The script runs against the scene you name: Summer opens it first (on its own, never in a batch with an edit), runs the script, then opens the scene you were looking at again. If the scene cannot be opened, the script does not run. The result says what happened in `scene_target`. Without `scenePath` it runs against the open scene, as before.
+- **Engine operations in the 4.0 catalog.** Every engine tool keeps its 3.x name and is now an operation with a title, a summary of 300 characters or fewer, its effect and an example (`src/core/ops/engine.ts`). On the v4 surface each engine tool lists that summary plus a pointer to its full guide, its hints come from its effect, and it answers in the one answer shape: `{ok, status, result}`, or one error code with one next step (`engine_not_running` says to open the project, instead of plain text). The v4 engine tools list takes about half the tokens of the 3.x one.
+- **Each engine tool has a guide.** `summer_docs_read` with id `tool/<slug>` now also returns the tool's full how-to (`library/tools/<slug>/GUIDE.md`, the text the 3.x MCP description carries). `npm run generate:tool-guides` keeps the two the same.
+- **Reads split from changes.** `summer_camera_bookmark` becomes `engine.list_camera_bookmarks` (read), `engine.save_camera_bookmark` and `engine.delete_camera_bookmark`; `summer_ui_actions` becomes `engine.list_ui_actions` (read) and `engine.invoke_ui_action`. On the v4 surface each is its own tool; the 3.x tools stay as they are.
+- **`summer_call` for engine operations**: a dry run checks the input without the engine, `ops.describe` answers for local operations here, and a bad input points at the tool's guide.
+- **Skills teach one script for multi-step scene work.** 28 code blocks in 23 skills chained 4 to 15 single scene edits (`summer_add_node`, `summer_set_prop`, ...), 197 calls in all; each is now one `summer_run_script` call with `scenePath` (the kit-placement example is one `summer_batch`). `scene-scripting` is stable and under 200 lines, with the extended ctx API and the recipes in its `references/`. AGENTS.md, `/summer`, `using-summer`, `make-game` and the agent playbook say it once each: 3 or more scene edits are one `summer_run_script` with `scenePath`. 46 script lines in 10 skills that wrote `var x := ctx.…` (which does not compile: `ctx` is untyped) now write `var x = ctx.…`. `validate:library` fails on a code block with 4 or more single scene edits (unless the line before it says why with `<!-- single-edits-ok: … -->`) and on `:= ctx.`.
+- **The operation contract.** `registry/schemas/operation.schema.json` describes an operation (name, effect, approval, input, output), and `registry/operations/legacy-names.json` maps every 3.x tool name to its operation (`summer_set_prop` is `engine.set_prop`, `summer_store_submit` is `store.publish`). Conformance fixtures sit next to it.
+- **Official MCP Registry.** `package.json` names the server `io.github.SummerEngine/summer` (`mcpName`), and the generated `server.json` lists the npm package and the hosted server. The name keeps the GitHub org's own case, because the registry matches it exactly against the org.
+- **The hosted 3.x tools ask for 3.x.** The local server mounts Summer's hosted 3.x tools (the 3.x surface and the legacy toolset), and `summer tool` and `summer doctor` call them, with `?surface=v3`, so they keep their 3.x names when Summer's hosted server serves 4.0 by default.
+- `summer doctor` checks for the tools of the surface `summer mcp` will serve (`summer_search` and `summer_call` on v4).
+- The per-call usage line also says which operation the call ran, the surface (`v3` or `v4`) and the profile. It never sends arguments or results.
+
+### Also in this release
+
+- **Setup never pins an older release.** When the CLI that runs `summer setup` was newer than npm `latest`, setup wrote `summer-engine@next` into the agent's MCP entry. `next` had stayed on 3.1.0, so the agent ran a release from September and silently lost `--assets-only`, `--profile` and every newer option. Setup now writes `next` only when `next` is this exact version; otherwise it pins this exact version (for example `summer-engine@4.0.0`), and a build that is not on npm keeps `latest` and says to use `--local-dev`. `--channel` (and `SUMMER_CHANNEL`) accepts an exact version, and the refresh command `summer doctor` prints follows the same rule.
+- The release steps (`docs/NPM_PUBLISH_QUICK_COMMANDS.md`) now point `next` at every new `latest` release and create the `v<version>` tag and GitHub Release from the CHANGELOG.
+- The `summer` banner no longer prints colour codes when `NO_COLOR` is set or the output is not a terminal (a log, a pipe, an agent's shell).
+- `summer setup notanagent` now says the agent name is unknown and lists the supported ones.
+- `summer setup codex` writes the MCP entry to `$CODEX_HOME/config.toml` when `CODEX_HOME` is set, where Codex reads it.
+- `summer setup <agent>` without `--yes` says to run it again with `--yes` to install the skills, instead of printing an internal command.
+- `summer setup` prints the first few installed skill names and how many more, not every name; `--json` still lists them all.
+- `summer_open` is marked as reaching outside the machine (`openWorldHint`), because it opens summerengine.com pages in the browser.
+- **The README starts with Connect.** Summer's hosted server, `https://mcp.summerengine.com/mcp`, comes first, with one install line for Claude Code, Codex, Cursor, VS Code, Devin Desktop and Claude Desktop (plus one-click buttons for Cursor and VS Code), then the local `npx -y summer-engine@latest mcp` server. The assets-only path offers the hosted server too, names the file formats (GLB, PNG, JPG, WebP, MP3, WAV, MP4) and says how to download a file for any engine or web app. The long agent install playbook is folded away on GitHub; agents still read all of it.
+- **The docs describe the shipped product.** Publishing to summer.games and Grow are listed as available, not "preview" and "planned", and the "not promised" note is gone. `tool/export-game`, `tool/publish-build`, `tool/capture-gameplay`, `skill/multiplayer-publish` and `skill/summer-analytics` are stable, and the tool reference lists the hosted store, publishing and Grow tools. (This carries over #97.)
+- **Fixed wrong statements:** `summer login` waits up to 15 minutes, not 120 seconds; AGENTS.md says publishing is `summer_publish_build` and then the owner's approval through `summer_store_submit` (the old creator command is gone); generation tools spend credits when they are called, so the README no longer says Summer never spends without a confirmation; the development guide no longer lists the removed `summer publish` and `summer releases`; the store sign-in files (`oauth-token`, `oauth-client`) are in the `~/.summer/` lists; GEMINI.md uses bare skill names. Every setup guide uses the same paste prompt and installs every skill (`--recommended` is the smaller opt-in set).
+- **`summer doctor` needs Node 20,** the same as the package's `engines` field. It accepted Node 18 before.
+- **Community files:** CONTRIBUTING.md, SECURITY.md (report privately through GitHub), CODE_OF_CONDUCT.md, issue forms for bugs and library entries, and a pull request template.
+- **CI** also builds and runs the CLI on macOS and Windows (Node 22) and on Node 20, runs with read-only permissions, and drops the old `v3-foundation` branch and the example-eval step that only printed SKIP.
+- **Fewer skills in every session.** The library-author skills (`skill-create`, `skill-improve`, `skill-test`, `writing-skills`) and the six research digests (`celeste-momentum-platforming`, `godogen-visual-proof-game-generation`, `lumera-single-image-scene-reconstruction`, `realtime-wet-surfaces`, `psx-retro-rendering`, `skintokens-auto-rigging`) no longer install with `summer setup` or the plugins. They stay in the library: `summer_docs_search` finds them, `summer_docs_read` reads them, and `summer skills install <name>` still installs one. Copies from an earlier setup stay until you delete them. A new `bundled: false` field in a skill's `resource.yaml` does this.
+- **Skill descriptions fit the hosts again.** Hosts put every installed skill's description into every session and cut what does not fit. The installed descriptions now total about 11,500 characters, down from about 17,300, and `npm run validate:library` fails when they pass 12,000. Library search ranks the same on the routing eval.
+- **Skill links work after install.** `summer setup` copies each skill folder alone, so 40 links like `../../references/mcp-tools-reference/mcp-tools-reference.md` (and 4 links into other skills' folders) were dead in the default install. They now name the library id to read (`summer_docs_read` id `reference/mcp-tools-reference`), and `validate:library` rejects any path that climbs out of a skill folder.
+- **Call examples are complete.** 65 call examples in ui-basics, 3d-lighting, design-level, design-npc, game-feel, art-direction and summer-apps left out a required argument, mostly `scenePath`, which the tool rejects. Each now passes it. `validate:library` checks every `summer_*` call example in the skills against the tool's `input_schema` (required arguments present, no unknown ones) and prints how many it checked.
+- **Errors carry a stable code.** When the engine is not running, the person is not signed in, the account has no credits or a Summer service cannot be reached, every tool now answers `{ok: false, code, error, recovery}`: `code` is `engine_not_running`, `not_signed_in`, `no_credits` or `unavailable`, the same codes the 4.0 tools use, and `recovery` is the one next step. The fields each tool sent before (`message`, `hint`, `status`) are still there. Generation, job, asset and Summer Apps tools used five different sign-in answers; they now use this one. The store sign-in keeps its own code, `store_login_required`.
+- **The engine-down answer works.** It told agents to run `npx -y summer-engine@latest run`, which fails without a project path. It now says to open the project in Summer Engine or run `summer run <project-path>`, and no longer shows token-file details. `summer tool` prints the same fields as JSON (exit 1) instead of saying "not running" twice.
+- **Network errors keep their cause.** "fetch failed" now says why, for example `connect ECONNREFUSED 127.0.0.1:443`, in the message and in `details.cause`.
+- `summer_list_my_assets` no longer says "Asset search requires an account" when you are not signed in.
+- **3D and motion generation return a job id at once.** `summer_generate_3d` and `summer_generate_motion` used to hold the agent for up to 10 minutes while the job ran. They now return the `jobId` within seconds, the same as Summer's hosted server, with a `next` line that says to poll `summer_check_job` until the status is `completed`. `wait: true` still blocks for scripts that cannot poll. `summer tool generate-3d` and `summer tool generate-motion` work the same way.
+- **The assets profile no longer points at engine tools.** With `--profile assets` (and `summer setup --assets-only`), `summer_get_agent_playbook`, the `summer_agent_playbook` prompt and `summer_start_game_task` told the agent to call `summer_get_project_context`, add nodes, play and take screenshots, none of which that profile has. They now answer with a no-engine version: ask what the asset is for, reuse before generating, confirm the spend, wait for the job, check the preview, and hand the file over with `summer_get_asset_download_url` (or `out` on `summer_generate_image`). The plan only names tools and skills the profile has, and says when a task needs the full setup instead.
+- **A session skill for the assets path.** The new `summer-assets` skill replaces `using-summer` in the assets-only install: what the session has, the loop, the file formats, and when an asset is done. `store-art` (Summer Games store art) left that install too.
+- **Every asset skill says what to do without Summer Engine.** The 23 skills in the assets-only install each have a short "Without Summer Engine" section: which steps to keep, which import and scene steps to skip, and how to hand the file over. A test fails when an asset skill has none.
+- `summer skills install --assets` (and `setup --assets-only`) no longer copies the Claude Code commands `/start`, `/summer` and `/gameskill`, which start and route engine work.
+- `summer_store_tools` names the tools it loads in the current profile (the Tool Factory and asset editing tools in `assets`, the store and publishing tools in `engine`) and carries its own tool hints and title.
+- `generate-motion` and `text-to-motion` no longer say `wait: true` is the default.
+
+## [3.9.1] - 2026-10-15
+
+Not published to npm: these changes ship in 4.0.0.
+
+3.9.0 was not published to npm; 3.9.1 is the first release with everything in 3.9.0 below, plus these changes.
+
+The Claude Code plugin gets a first-run guide and Summer's hosted server, and passes `claude plugin validate --strict`.
+
+- **`/summer:start`.** A new command for the first run: it checks what is on the machine, signs the user in, and gets a first game playing in about five minutes, from a template that already plays or from a board of concept art Summer draws in the chat (the hosted `summer_make_game`), built in the Summer Engine desktop app.
+- **Two MCP servers in the plugin.** `summer-engine` (the desktop bridge, as before) and the new `summer-cloud`, Summer's hosted server at `https://mcp.summerengine.com/mcp`, for people without the desktop app or Node. Sign in once with `/mcp`. Codex, Cursor and Factory keep the one local server.
+- **The session-start hook never waits.** It no longer runs `summer doctor` (npm registry, engine probe, MCP boot); it reads local files only and returns in well under a second. On a machine without Summer it tells the agent to suggest `/summer:start`.
+- **Clean manifests.** The Claude plugin and marketplace manifests carry only documented fields (no `_generated` banner, no Codex-only fields), plus the directory listing fields (icon, documentation, support, privacy and terms links). The plugin no longer names `hooks/hooks.json` (its default location) or declares the pre-commit doctor option, which opened a settings dialog on enable; `SUMMER_PRE_COMMIT_DOCTOR=1` still turns that hook on. The repo's own `CLAUDE.md` moved to `.claude/CLAUDE.md`, because a `CLAUDE.md` at the plugin root fails the strict check.
+- README and `docs/CLAUDE_CODE.md` show the one-line plugin install: `/plugin install summer --marketplace summerengine/summer`.
+- The once-per-session usage line now names your agent app (the name it sent in the MCP handshake) and goes out on the first tool call of any kind, not only the first engine tool. `SUMMER_NO_TELEMETRY=1` or `DO_NOT_TRACK=1` still turns it off.
+
+## [3.9.0] - 2026-10-14
+
+One sign-in for every Summer tool, tool profiles that fit every agent, shorter tool results, and Summer sees which agent app made each request.
+
+- **Summer sees which agent app made each request.** Every request to Summer's servers (generation, jobs, assets, Summer Apps, the store upload, the hosted Summer Engine MCP, library search and the usage line) now carries the agent app's id (`X-Summer-Agent-Host`, for example `claude-code`), the name and version the app sent in the MCP handshake, and the tool that made the request (`X-Summer-MCP-Tool`). Before, the app was never sent. Outside an MCP session (`summer tool`, `summer login`) the id comes from the agent's environment; `SUMMER_AGENT_HOST` overrides it. `SUMMER_NO_TELEMETRY=1` or `DO_NOT_TRACK=1` removes these headers and keeps only the CLI's own name and version.
+- **One sign-in.** `summer login` now signs you in to your Summer account and then, in the same browser, to the store, publishing and Grow tools: one Allow click, or none if this machine was approved before. Before, that took a second `summer login --store`. If the store step does not finish within 3 minutes, your account sign-in is kept and `summer login --store` adds the store later. `summer login --no-store` skips the store step; `summer login --store` still runs it alone.
+- **Every tool says what it does.** Each local MCP tool now carries `readOnlyHint`, `destructiveHint`, `idempotentHint` and `openWorldHint`, mapped from its `authority` in the library. Agents and apps that ask before a change can let reads run and still ask before an edit, a generation that costs credits, or a publish. A test fails when a tool has no hints.
+- **Agents script runs of scene edits.** The MCP instructions now say: more than 3 scene edits, write one `summer_run_script` (snapshot, script, diff, screenshot). After the 4th single edit in a row (`summer_set_prop`, `summer_add_node`, `summer_remove_node`, ...), the result adds one line that points to `summer_run_script`, then again every 6th.
+- **Tool profiles.** `summer mcp --profile` (env `SUMMER_PROFILE`): `full` is every tool and stays the default, so existing setups do not change. `engine` has the engine, generation and store tools and stays under 128 tools; `summer setup vscode-copilot` now writes it, because VS Code Copilot takes at most 128 tools per request (`--profile full` keeps every tool). `assets` has generation, the asset library, account and library search, and no engine tools. `--toolsets` (env `SUMMER_TOOLSETS`) adds toolsets by name. Engine tools load at start in every profile that has them, and no tool is renamed.
+- **Assets-only setup.** `summer setup <agent> --assets-only` writes the `assets` profile, installs only the asset skills instead of the whole library, and leaves out Summer Games. The README's assets-only path now uses it. `summer skills install --assets` installs the same skills.
+- **Shorter results.** Tool results are compact JSON instead of pretty-printed JSON. Results that can be long (scene and runtime trees, console and debugger reads, inspect reads, library reads) stop at a default size and say so: 4,000 characters, 8,000 for `summer_get_scene_tree`, 24,000 for `summer_read_library`. Pass `maxCharacters` for more. Writes, job ids and file reads are never cut.
+- **Usage reports.** When you are signed in, the MCP server now reports each tool call to Summer: the tool name, whether it worked, how long it took and your agent app's name. Nothing else: no arguments, results, code or file names. `SUMMER_NO_TELEMETRY=1` or `DO_NOT_TRACK=1` turns it off, and now also turns off the once-per-session report.
+- `summer_app_guide` starts with section `overview` by default and answers Markdown text instead of one long JSON line; `all` still returns every section.
+- `summer_app_screenshot` takes `steps` (click a selector, press a declared action, wait) to show a dialog or a second state before the capture, and waits until the app's calls settle.
+
 ## [3.8.0] - 2026-10-13
 
 Agents build Summer Apps, team tools inside Summer Studio, and asset-only requests skip the engine.

package/GEMINI.md

@@ -1,6 +1,6 @@
 # Summer — Gemini Context
 
-You have the Summer extension installed: the `summer-engine` MCP server plus Summer skills under the `summer:` namespace.
+You have the Summer extension installed: the `summer-engine` MCP server plus the Summer skills, each under its bare slug (`using-summer`, `fps-controller`).
 
 The full agent guide lives in `AGENTS.md`, next to this file — trust, the six library kinds, how to search the registry index, the critical engine rules, and the verification ladder. Read it before working.
 
@@ -8,5 +8,5 @@ The full agent guide lives in `AGENTS.md`, next to this file — trust, the six
 
 Gemini-specific notes:
 
-- Activate skills via `activate_skill`. Start every Summer Engine session with `summer:using-summer`.
-- If skills aren't loading or the MCP server fails: `npx -y summer-engine@latest setup gemini --yes --force`, then `npx -y summer-engine@latest doctor`.
+- Activate skills via `activate_skill`. Start every Summer Engine session with `using-summer`.
+- If skills aren't loading or the MCP server fails: `npx -y summer-engine@latest setup antigravity --yes --force` (Antigravity), or `npx -y summer-engine@latest setup gemini --yes --force` for this Gemini CLI extension (a legacy target that still works), then `npx -y summer-engine@latest doctor`.

package/README.md

@@ -1,15 +1,15 @@
-# Summer: MCP server, CLI and skills for Summer Engine
+# Summer Engine: MCP server, CLI and skills
 
 <div align="center">
 
 <img src="docs/brand/sun.png" alt="" width="128">
 
-### Let any AI coding agent build games in Summer Engine.
+### The game engine built for AI.
 
-**MCP server · game-dev skills · `summer` CLI. One npm package: `summer-engine`.**
+**Any agent builds, tests and publishes a full multiplayer game. MCP server · game-dev skills · `summer` CLI, in one npm package: `summer-engine`.**
 
 [![npm](https://img.shields.io/npm/v/summer-engine?label=npm&color=f7b731)](https://www.npmjs.com/package/summer-engine)
-[![downloads](https://img.shields.io/npm/dm/summer-engine?label=installs&color=f7b731)](https://www.npmjs.com/package/summer-engine)
+[![downloads](https://img.shields.io/npm/dm/summer-engine?label=downloads&color=f7b731)](https://www.npmjs.com/package/summer-engine)
 [![license](https://img.shields.io/badge/license-MIT-1a1a1a)](LICENSE)
 
 [**Website**](https://www.summerengine.com) · [**Docs**](https://docs.summerengine.com) · [**CLI setup**](https://www.summerengine.com/cli) · [**MCP setup**](https://www.summerengine.com/mcp)
@@ -18,13 +18,40 @@
 
 ---
 
+## Install
+
+- **Chat apps** (Claude, ChatGPT, Cursor...): add `https://mcp.summerengine.com/mcp`. Nothing to install.
+- **Homebrew:** `brew install summerengine/tap/summer`
+- **npm** (Node 20+): `npm install -g summer-engine`
+
+**CLI only** (summer-engine 4.2.0 or newer), no MCP server: `summer setup --cli`. `summer ops search "publish my game"` finds any operation, signed in or not.
+
+## Connect
+
+**Cloud work: `https://mcp.summerengine.com/mcp`.** Nothing to install. Add the URL to your agent and sign in to your Summer account once. Your agent then makes assets (images, 3D models, motion, sound effects, music, voices, video), searches and downloads your Summer asset library, plans games, and runs your projects, the store, publishing, prices, analytics, A/B tests, your team and Studio. It has no engine tools: for those, use the local server below.
+
+| Agent | Add the hosted server |
+|---|---|
+| Claude Code | `claude mcp add --transport http summer-cloud https://mcp.summerengine.com/mcp`, then `/mcp` to sign in |
+| Codex | `codex mcp add summer-cloud --url https://mcp.summerengine.com/mcp`, then `codex mcp login summer-cloud` |
+| Cursor | [Add to Cursor](https://cursor.com/install-mcp?name=summer-cloud&config=eyJ1cmwiOiJodHRwczovL21jcC5zdW1tZXJlbmdpbmUuY29tL21jcCJ9), or add `"summer-cloud": {"url": "https://mcp.summerengine.com/mcp"}` under `mcpServers` in `~/.cursor/mcp.json` |
+| VS Code | [Add to VS Code](https://vscode.dev/redirect/mcp/install?name=summer-cloud&config=%7B%22type%22%3A%22http%22%2C%22url%22%3A%22https%3A%2F%2Fmcp.summerengine.com%2Fmcp%22%7D), or `code --add-mcp '{"name":"summer-cloud","type":"http","url":"https://mcp.summerengine.com/mcp"}'` |
+| Devin Desktop (formerly Windsurf) | add `"summer-cloud": {"serverUrl": "https://mcp.summerengine.com/mcp"}` under `mcpServers` in `~/.config/devin/mcp_config.json` (Windows `%APPDATA%\devin\mcp_config.json`) |
+| Claude Desktop, claude.ai | Settings > Connectors > Add custom connector, then paste the URL |
+
+**Engine work: `npx -y summer-engine@latest setup <agent> --yes`** (needs Node 20+). It writes the local server (`summer mcp`) into your agent's config with the skills. The local server drives the Summer Engine app on your machine: build scenes, write scripts, play the game, take screenshots, read errors. After `summer login` it also runs every cloud operation, so your agent needs one server. Or paste the prompt in [Get started](#get-started-one-prompt) and your agent does every step.
+
+**CLI only (summer-engine 4.2.0 or newer): `npx -y summer-engine@latest setup <agent> --cli --yes`.** No MCP server: your agent runs Summer as commands in its shell. Setup installs the skills for your agent, with `summer-cli`, the guide to the commands, and writes no MCP entry. Your agent signs you in with `summer login`, finds an operation with `summer ops search "<what you want>"` and runs it as `summer <area> <action> --<field> <value>`, with `--dry-run`, `--wait` and `--json`. Engine commands (`summer engine …`) drive the Summer Engine app on your machine. Each skill ends with a table of the command for every tool it names. Add `--assets-only` for only the asset skills. `--no-mcp` is the same as `--cli`.
+
+**ChatGPT and Claude's connector directory** use two reviewed store versions with a fixed tool list: `https://mcp.summerengine.com/chatgpt` (games, assets and generation; no publishing, no billing links) and `https://mcp.summerengine.com/directory` (the store, publishing and Grow reads; no image, 3D, audio or video generation). They keep their 3.x tool names and have no `summer_search` or `summer_call`. For everything else, use `/mcp`.
+
 ## What this is
 
-[Summer Engine](https://www.summerengine.com) is a desktop game engine. This repo connects your AI coding agent (Claude Code, Cursor, Codex, Copilot and many more) to it, the way an MCP server for Blender connects an agent to Blender, but for making whole games.
+[Summer Engine](https://www.summerengine.com) is the game engine built for AI. This repo connects your AI coding agent (Claude Code, Cursor, Codex, Copilot and many more) to it: the agent builds a whole game in the engine, tests it, publishes it to [summer.games](https://summer.games) and reads how players play it.
 
 | Part | What it does |
 |---|---|
-| **MCP server** (`summer mcp`) | Tools your agent calls to drive the running editor: build scenes, write scripts, play the game, take screenshots, read errors. |
+| **MCP server** (`summer mcp`) | Tools your agent calls to drive the running editor: build scenes, write scripts, play the game, take screenshots, read errors. After `summer login` it also runs the cloud operations: assets, plans, the store, publishing, prices and analytics. |
 | **Skills** | Game-dev know-how your agent loads: movement, combat, multiplayer, VFX, audio, UI, level design and more. |
 | **CLI** (`summer`) | Installs the engine, signs you in, sets up your agent, creates projects from templates and publishes games. |
 
@@ -34,13 +61,30 @@ With Summer installed, your agent can:
 
 - **Build real games**: scenes, scripts, physics and UI, through live MCP tools.
 - **Build multiplayer games** on Summer's own networking: matchmaking, parties, leaderboards, player data and world saves.
-- **Add analytics** to see how players play.
-- **Publish games** to the [summer.games](https://summer.games) store.
+- **Add analytics** to the game and read it back: store page views, launches, play sessions, play time and your own events.
+- **Publish games** to the [summer.games](https://summer.games) store: the store page, art, the build, a private preview link and the release. Summer's store review runs before anything goes live.
 - **Use proven recipes**: skills, templates and references, all searchable through one index.
 - **Check its own work**: play the game, take screenshots, read the debugger, press real keys.
 - **Resume any project**: `.summer/` project memory lets a fresh agent pick up where the last one stopped.
 
-You stay in control of every change and release. Summer never publishes, installs, or spends without your explicit confirmation, and library entries are structurally prevented (by a capability lint in CI) from instructing agents to touch the network, credentials, or package managers.
+### You decide what your agent may do
+
+Studio > Settings > Agent permissions has six switches. They apply to every app you connect, like Claude or ChatGPT. These defaults apply now. You can change them soon. Until then, Summer Games still asks the game's owner before an agent publishes, and price, A/B test and member changes ask you first.
+
+| Switch | Default | What the agent may do without asking |
+|---|---|---|
+| Make and build | on | Edit drafts, scenes, plans and uploads, and start builds. |
+| Spend credits | on | Generate assets and run paid builds, within your credits and your auto top-up limit. |
+| Publish | on | Publish store pages, versions and releases. Summer's store review still runs first. |
+| Prices and live changes | on | Change prices and sales, start or stop A/B tests, change member roles. |
+| Delete for good | off: asks | Delete games, assets, pages and releases. |
+| Contact people | off: asks | Send invites and other emails to real people. |
+
+When a switch is off, the agent asks you first. It gives you a link (`https://www.summerengine.com/studio/approvals/<id>`), and an open Studio tab shows the request with Approve and Decline. Nothing changes until you approve. The agent always asks before it changes agent permissions or auto top-up, enters a jam, or changes the analytics event limit. Studio > Settings > Agent activity lists what agents changed or asked for, newest first, with Undo for prices, sales, country prices, member roles, team names and the event limit.
+
+Generation and paid builds spend your Summer credits. Turn on auto top-up in Studio Billing: when your credits fall below an amount you pick, Summer adds the amount you choose, up to a monthly limit you set. Agents can never change auto top-up on their own. When credits run out, your agent gets the error `no_credits` with one link: https://www.summerengine.com/studio/credits.
+
+Summer never installs software without your explicit confirmation. Library entries are structurally prevented (by a capability lint in CI) from instructing agents to touch the network, credentials, or package managers.
 
 ## Get started: one prompt
 
@@ -61,21 +105,34 @@ In most agents (Claude Code, Codex, Cursor, GitHub Copilot (VS Code, CLI, JetBra
 
 Then ask the agent to build something.
 
+### Claude Code: the Summer plugin
+
+In Claude Code, type:
+
+```text
+/plugin install summer --marketplace summerengine/summer
+```
+
+Then type `/summer:start`. It signs you in and gets a first game playing in about five minutes: from a template that already plays, or from a plan of concept art Summer draws for your idea right in the chat, built in the Summer Engine desktop app. The plugin brings Summer's skills and two MCP servers: `summer-engine` drives the desktop app (needs Node), and `summer-cloud` is Summer's hosted server (sign in once with `/mcp`). Use the plugin or `summer setup claude-code`, not both: they install the same skills.
+
 ### Only want assets?
 
-Sound effects, music, voices, images, 3D models and video are made on Summer's servers, so you do not need the Summer Engine app for them. Paste this instead:
+Sound effects, music, voices, images, 3D models, motion and video are made on Summer's servers, so you do not need the Summer Engine app for them. The quickest way is the hosted server in [Connect](#connect): no Node, no install. To get the asset skills too, paste this instead:
 
 > Connect Summer to this agent so I can make game assets. Read github.com/summerengine/summer, connect yourself to Summer and log me in. Skip the Summer Engine app and the starter project, I only want assets.
 
-The agent installs the skills and the MCP config and signs you in. It does not download the engine. Each asset lands in your Summer library, so a game project (in Summer Engine or anywhere else) can use it later.
+The agent installs the asset skills and the MCP config (summer-engine 4.0.0 or newer) and signs you in. It does not download the engine. Each asset lands in your Summer library as a normal file: GLB for 3D models, PNG, JPG or WebP for images, MP3 or WAV for audio, MP4 for video. The agent saves each file into your project (your engine's asset folder, or the folder you name), so any engine or web app can use it.
 
 ---
 
 ## AGENTS READING THIS: install playbook
 
+<details>
+<summary>The step-by-step install playbook your agent runs (humans can skip it)</summary>
+
 You are an AI coding agent. The user told you to install Summer Engine. **Run this playbook via your shell**: Bash on macOS/Linux or PowerShell on Windows. Detection first, then only install what's missing. (Once installed, your working guide is [`AGENTS.md`](AGENTS.md).)
 
-**Assets only.** If the user only wants assets (sound effects, music, voices, images, 3D models, video), not a game built in Summer Engine, or tells you to skip the engine: run Step -1, Step 0, Step 1 with `--no-games` added (Summer Games is for playing with friends, and leaving it out saves a second sign-in), and Step 3, then stop installing. Skip Step 2 (the engine download), Step 5 and Step 6. On this path the doctor warnings for `engine-install` and `local-api` are expected; leave them. The asset tools (`summer_generate_audio`, `summer_generate_sfx_choices`, `summer_generate_image`, `summer_generate_3d`, `summer_generate_video`, `summer_search_assets`) run on Summer's servers and need only the login. Most agents load a new MCP server only after a restart. Until then, call the same tool from the shell: `npx -y summer-engine@latest tool <slug> --args '<json>'` (`summer tool --list` prints the slugs). For example, three versions of one sound for the user to pick from: `npx -y summer-engine@latest tool generate-sfx-choices --args '{"text":"sword clash"}'`. Each asset lands in the user's Summer library.
+**Assets only.** If the user only wants assets (sound effects, music, voices, images, 3D models, video), not a game built in Summer Engine, or tells you to skip the engine: run Step -1, Step 0, Step 1 with `--assets-only` added, and Step 3, then stop installing. `--assets-only` writes the `assets` tool profile (generation and asset tools, no engine tools), installs only the asset skills, and leaves out Summer Games (it is for playing with friends, and leaving it out saves a sign-in). Skip Step 2 (the engine download), Step 5 and Step 6. On this path the doctor warnings for `engine-install` and `local-api` are expected; leave them. The asset operations (`assets.generate_audio`, `assets.generate_sfx_choices`, `assets.generate_image`, `assets.generate_3d`, `assets.generate_video`, `assets.search`) run on Summer's servers and need only the login. Most agents load a new MCP server only after a restart. Until then, run the same operation from the shell: `npx -y summer-engine@latest <area> <action> --<field> <value>` (`summer ops search <words>` finds one and its input). For example, three versions of one sound for the user to pick from: `npx -y summer-engine@latest assets generate-sfx-choices --text "sword clash"`. Each asset lands in the user's Summer library; `out` (a folder or a file path) on the call saves it on this machine and the answer gives `localPath`, and `assets.get` returns a `downloadUrl` for use outside Summer Engine.
 
 **Windows PowerShell: type `npx.cmd` wherever this playbook says `npx`.** Plain `npx` in PowerShell runs `npx.ps1`, which Windows blocks by default ("running scripts is disabled on this system"). `npx.cmd` is the same command without that block. Never change the execution policy or turn off Windows Defender to work around it. Bash (including Git Bash on Windows) can use plain `npx`.
 
@@ -139,7 +196,7 @@ Replace `claude-code` with the user's actual agent: `claude-desktop`, `codex`, `
 
 **First-install detection:** if `~/.claude/skills/` didn't exist before this command, Claude Code wasn't watching it and won't auto-detect the new files this session. Tell the user **once**: "Skills installed - restart your agent so they load." On subsequent installs (directory already existed), skills auto-detect mid-session and no restart is needed. **You can detect first-install vs upgrade by checking if `~/.claude/skills/` existed before Step 1; record the result before running setup.**
 
-**Do NOT run `/plugin install` or any slash command.** The CLI is the supported install path; the plugin marketplace is only for users who ask for it.
+**Do NOT run `/plugin install` or any other slash command.** An agent cannot type them; this playbook installs through the CLI. The Claude Code plugin (above) is the user's own one-step choice. If the user already installed it, skip Step 1: the plugin and `summer setup` install the same skills.
 
 ### Step 2: Install the engine app (only if `engine-install` needs attention)
 
@@ -159,7 +216,7 @@ npx -y summer-engine@latest install
 npx -y summer-engine@latest login
 ```
 
-This opens the user's default browser. **Tell the user**: "Your browser is opening now. Click sign-in once and come back to this terminal." The CLI waits up to 120 seconds for the sign-in, checks the returned identity, and stores the session in `~/.summer/`, which the engine shares. **If the user takes longer than 120 seconds, re-run `npx -y summer-engine@latest login` once and tell them to come back to the terminal quickly.** Don't loop.
+This opens the user's default browser for one sign-in that covers every Summer tool: first the Summer account ("Yes, Sign In"), then, in the same browser, a "Welcome to Summer CLI" page for the store, publishing and Grow tools (one Allow click; none if this machine was approved before). **Tell the user**: "Your browser is opening now. Sign in, click Yes, Sign In, then Allow on the next page, and come back to this terminal." The CLI checks the returned identity and stores the session in `~/.summer/`, which the engine shares. If the store step does not finish within 3 minutes, the account sign-in is still saved; `summer login --store` adds the store later. Don't loop.
 
 ### Step 4: Re-run doctor to confirm
 
@@ -206,7 +263,7 @@ Once `local-api` is `ok`, MCP tools are safe to call.
 
 ### Step 6: Brainstorm the game, then build
 
-Now you have skills + MCP. **Don't jump into `summer create` content from a vague prompt**. Call `summer_start_game_task` with the user's goal, then invoke the recommended skill. For vague "make a game" requests, that should usually be the `brainstorm-game` skill (installed skills are invoked by their bare slug — there is no `summer:` prefix). It scopes mechanics, art direction, and the V1 cut list, and writes the result to `.summer/GameSoul.md`. Every other Summer skill reads from that file.
+Now you have skills + MCP. **Don't jump into `summer create` content from a vague prompt**. Plan the task first: `summer_call` with `{"op": "docs.plan", "input": {"goal": "<the user's goal>"}}` (from a shell: `summer plan <goal>`), then invoke the recommended skill. For vague "make a game" requests, that should usually be the `brainstorm-game` skill (installed skills are invoked by their bare slug — there is no `summer:` prefix). It scopes mechanics, art direction, and the V1 cut list, and writes the result to `.summer/GameSoul.md`. Every other Summer skill reads from that file.
 
 Project memory lives in `.summer/` as readable Markdown. Use `.summer/memory/` for locked facts that should not drift across sessions, such as character voice IDs, world canon, and provider bindings. Users can inspect it with `summer memory`; agents should read relevant memory surfaced by `summer_get_project_context` before changing creative/audio/dialogue/level/character work.
 
@@ -225,13 +282,15 @@ Only skip brainstorm if the user explicitly said "skip brainstorm" or "just buil
 - **Don't drop `@latest` from the npx commands.** `npx -y summer-engine` (no version pin) serves whatever's in npx's local cache, which can be a stale older version. The `@latest` tag forces npm to re-resolve from the registry. If a user reports "unknown command 'doctor'" or sees a much smaller skill list than expected, they got cache-served. Tell them to run `npx clear-npx-cache` then retry with `@latest`.
 - **Don't call MCP tools (`summer_get_scene_tree`, etc.) until `local-api` is `ok`.** The engine takes a few seconds to boot after `summer run`. Use Step 5b's wait-loop.
 - **Don't `summer create` without `cd`'ing to a stable parent directory first.** It writes into CWD; agents that start in a temp dir will leave the project there.
-- **Don't loop `summer login` if it times out at 120s.** Re-run it once and tell the user to be quicker; loop forever and the user is stuck.
+- **Don't loop `summer login` if it times out.** It waits up to 15 minutes for the account sign-in. Re-run it once and tell the user to finish "Yes, Sign In" in the browser tab it opens; loop forever and the user is stuck.
 - **Don't jump straight into `summer create` from a vague prompt.** Invoke the `brainstorm-game` skill first (Step 6). The build skills assume `.summer/GameSoul.md` exists.
 
 **Using a different agent?** Use its id from Step 1 (aliases such as `devin`, `agy` and `droid` also work; see the [CLI reference](#cli-reference)). Skill folders vary per agent; the CLI handles the difference, and [`integrations/README.md`](integrations/README.md) documents exactly what gets written where for every client. After install, **Cline users should restart VS Code** so the extension reloads its MCP config. **VS Code Copilot users** should start the `summer-engine` MCP server from Agent mode if VS Code does not autostart it.
 
 If the user wants `summer` on their `PATH` for everyday terminal use, a global npm install works too. The agent flow doesn't need it.
 
+</details>
+
 ---
 
 ## The lifecycle: create → test → publish → grow
@@ -240,8 +299,23 @@ If the user wants `summer` on their `PATH` for everyday terminal use, a global n
 |---|---|---|
 | **Create** | Available | Scaffold from a pinned template, build scenes and scripts through MCP, generate 2D/3D/audio/video assets, guided by the library. |
 | **Test** | Available | The verification ladder: compile checks, screenshots, live play with debugger reads, and input-driven probes (`RunVerification`) that press real keys and assert on real frames. |
-| **Publish** | Preview | `summer_export_game` exports the game with the installed engine (headless); `summer_publish_build` uploads it to your game's summer.games store listing after you confirm the exact game, file and version (sign in once with `summer login --store`). Nothing is submitted silently. |
-| **Grow** | Planned | Analytics, retention and live-ops tooling will arrive as new library entries. Not part of this package yet. |
+| **Publish** | Available | `summer_export_game` builds the store file with the installed engine; `store.upload_file` uploads it after you confirm the exact game, file and version. `store.update_listing`, `store.set_art` and `store.set_trailer` write the store page (text, tags, long description, support contact, release date, art, trailer); `store.preview_link` makes a private preview link; `store.publish` sends the game to Summer's store review; `store.status` shows the review and the releases; `store.release` ships an approved build. With the Publish switch off, the agent asks you first. |
+| **Grow** | Available | `analytics.overview` and `analytics.summary` read store page views, launches, play sessions, play time and your game's own events (see the `summer-analytics` skill). `pricing.*` sets prices, country prices and sales; `experiments.*` runs store page A/B tests; `games.members` and the member operations manage who works on a game; `marketing.*` applies for Summer's growth services. |
+
+These are operations on the hosted Summer server; the local server runs them too after `summer login`.
+
+## How agents call Summer
+
+Every capability is an operation named `<area>.<action>`: `assets.generate_image`, `store.publish`, `pricing.set_base`.
+
+- **Direct tools** cover the common jobs: `summer_` plus the operation name, with `_` for `.` (`games.list` is `summer_games_list`). Engine tools keep their 3.x names (`summer_add_node`, `summer_run_script`, `summer_play`, `summer_screenshot`), and makers keep `summer_tool_<slug>`.
+- **Everything else**: `summer_search` finds the operation for a job you describe in words and returns its exact input. `summer_call` runs it: `{op, input, dryRun?, idempotencyKey?}`.
+- **One answer shape**: `done` with a `result`, `running` with a job (`summer_jobs_wait` waits up to 50 seconds per call), `needs_approval` with a link for you, `dry_run` with a preview, or an error with a `code`, a `message` and exactly one `next` step.
+- **Safe to try**: every change takes `dryRun: true` (it changes nothing and spends nothing; a spend shows your own credit estimate) and an `idempotencyKey`, so a retry never runs twice.
+- **Error codes**: `invalid_input`, `not_signed_in`, `forbidden`, `not_found`, `conflict`, `idempotency_conflict`, `in_progress`, `rate_limited`, `no_credits`, `over_limit`, `engine_not_running`, `engine_lacks_op`, `unsupported`, `not_in_profile`, `moved`, `outcome_unknown`, `unavailable`, `internal`.
+- **3.x names keep working** for all of 4.x: `summer_call` accepts them on every server, `summer mcp --toolsets legacy` lists them on the local server, and the local server lists them by itself while your installed skills are older than 4.0. Its first start after an upgrade refreshes the Summer skills you installed, so after an upgrade the legacy list stays off unless you ask for it. The map from old names to operations is [`registry/operations/legacy-names.json`](registry/operations/legacy-names.json).
+
+The same operations run from a shell: `summer <area> <action> --<field> <value>` (for example `summer assets generate-image --prompt "a cozy pixel-art tavern" --aspect-ratio 16:9`), with `--dry-run`, `--wait` (follows a job or an approval to the end) and `--json` (prints the answer only; exit code 0 for any `ok` answer, 1 for an error). `summer whoami` shows who is signed in. `summer ops search <words>` and `summer ops describe <op>` find an operation and its input. Every command that reads something takes `--json`.
 
 ## What's in this repo
 
@@ -259,8 +333,13 @@ summer/
 ├── registry/          # schemas + generated/ (the compiled index everything reads; never hand-edited)
 ├── evals/             # evidence the library works: routing, skills, examples, templates, tools, end-to-end
 ├── integrations/      # one folder per supported agent: what gets installed where
+├── commands/          # the shipped slash commands (/summer, /gameskill, the plugin's /summer:start)
+├── hooks/             # lifecycle hooks: session-start orientation, opt-in pre-commit doctor
+├── assets/            # files the tools ship with: offline API docs, engine-side probe and audit scripts
 ├── scripts/           # generate-registry (the compiler), validate-library (schema + capability lint)
-└── docs/              # development guide, migration notes, design contract
+├── tests/             # v2 prose behaviour specs (the code tests sit next to the code in src/)
+├── docs/              # development guide, migration notes, design contract
+└── .claude-plugin/ …  # plugin manifests for Claude Code, Codex, Cursor and Factory (generated)
 ```
 
 One rule ties it together: **every entry is described once** (a `resource.yaml` in `library/`), and the registry compiler generates everything else — the searchable index, every agent plugin manifest, the skill installer data, counts, and legacy aliases. CI fails on any drift. See [`docs/design/CONTRACT.md`](docs/design/CONTRACT.md).
@@ -276,7 +355,7 @@ Six kinds of entry, all searchable through the same generated index:
 - **References** — facts: engine version compatibility, GDScript style, tool references.
 - **Tools** — the executable capabilities themselves, described in the same registry so agents can discover what they can do.
 
-Agents don't browse folders; they search the compiled index (`registry/generated/index.json`) through `summer_search_library` (or `summer tool search-library`) by summary, use-cases, and facets, then load the hit with `summer_read_library`. IDs are permanent, so feedback and evidence follow an entry across any reorganization.
+Agents don't browse folders; they search the compiled index (`registry/generated/index.json`) through `summer_docs_search` (or `summer tool search-library`) by summary, use-cases, and facets, then load the hit with `summer_docs_read`. IDs are permanent, so feedback and evidence follow an entry across any reorganization.
 
 ## The ecosystem
 
@@ -320,7 +399,7 @@ Official entries land in this repo by PR, gated by schema validation and the cap
 
 ## Library feedback
 
-- Agents can report how an entry worked (`summer_library_feedback`): worked / worked with fixes / wrong / outdated / incomplete / did not apply / misrouted. What is sent, in full: the entry ids, one outcome word each, an optional note and deviation (280 characters max, about the entry), the engine version, the agent's self-reported model id, this CLI's version, the host app name/version, a random per-process session id, and — only when logged out — a random install uuid (when logged in, the account token is sent instead). **The schema cannot carry your code, files, or chat.** The very first call on a machine sends nothing and returns a notice; `SUMMER_NO_TELEMETRY=1` or `DO_NOT_TRACK=1` turns it off entirely.
+- Agents can report how an entry worked (`summer_call` with `docs.feedback`): worked / worked with fixes / wrong / outdated / incomplete / did not apply / misrouted. What is sent, in full: the entry ids, one outcome word each, an optional note and deviation (280 characters max, about the entry), the engine version, the agent's self-reported model id, this CLI's version, the host app name/version, a random per-process session id, and — only when logged out — a random install uuid (when logged in, the account token is sent instead). **The schema cannot carry your code, files, or chat.** The very first call on a machine sends nothing and returns a notice; `SUMMER_NO_TELEMETRY=1` or `DO_NOT_TRACK=1` turns it off entirely.
 - Today those reports land in a write-only mailbox that maintainers read. Only verified outcomes count; popularity never ranks an entry.
 
 ## What gets downloaded
@@ -332,13 +411,13 @@ We tell you before we touch your disk.
 | `summer-engine` npm package (CLI + MCP + library) | ~2 MB download, ~6 MB unpacked | first `npx -y summer-engine@latest ...` call | [npmjs.com/package/summer-engine](https://www.npmjs.com/package/summer-engine) |
 | Summer Engine app | ~1 GB (engine + bundled Git/runtime tools) | `npx -y summer-engine@latest install` | Summer's signed releases |
 | Auth token | ~1 KB | `npx -y summer-engine@latest login` | Browser to `~/.summer/auth-token` |
-| Store sign-in | ~2 KB | only when you run `summer login --store` | Browser OAuth (PKCE, loopback port 47615-47617) to `~/.summer/oauth-token` with its refresh token, plus this machine's public client id in `~/.summer/oauth-client`; never replaces the auth token |
+| Store sign-in | ~2 KB | `summer login` (right after the account sign-in), or `summer login --store` alone | Browser OAuth (PKCE, loopback port 47615-47617) to `~/.summer/oauth-token` with its refresh token, plus this machine's public client id in `~/.summer/oauth-client`; never replaces the auth token |
 | Skill files | small, bundled | in the npm package | no extra network call |
-| Generated assets (3D / image / audio / video) | varies | only on explicit `summer_generate_*` calls when that provider route is enabled for the account | Summer Engine Studio |
+| Generated assets (3D / image / audio / video) | varies | only on explicit `assets.generate_*` calls | Summer Engine Studio |
 | URL imports | varies | only on explicit `summer_import_from_url` calls | the URL you provide |
 
 Not downloaded, not collected:
-- No background telemetry. Diagnostics stay local. The only network report is the opt-out library feedback mailbox described above.
+- No background telemetry. Diagnostics stay local. Two network reports exist, both off with `SUMMER_NO_TELEMETRY=1` or `DO_NOT_TRACK=1`: the library feedback mailbox described above, and, only when you are signed in, a usage line when an MCP session starts and one per tool call (the tool name, success, duration and your agent app's name; never arguments, results, code or file names) with your account token, so Summer can see which tools work in which agents. Requests to Summer's servers (generation, assets, the store) also name your agent app, its version and the tool in headers; the same two variables remove them.
 - No silent engine updates. `summer install` checks the installed version and asks before replacing it (or needs `--yes`); nothing updates the engine behind your back.
 - No model weights. AI generation runs in Summer Engine Studio (cloud), never on your machine.
 
@@ -348,39 +427,40 @@ Not downloaded, not collected:
 |---|---|---|
 | **Summer** (this repo: CLI, MCP server, library, integrations) | **MIT** | [summerengine/summer](https://github.com/summerengine/summer) |
 | **Summer Engine app** (the desktop editor and runtime) | free to download, closed source for now | [summerengine.com/download](https://summerengine.com/download) |
-| **Hosted Summer integrations** | availability and terms vary by rollout; preview features are labeled in the CLI | [summerengine.com/pricing](https://summerengine.com/pricing) |
+| **Hosted Summer services** (store, publishing, Grow, multiplayer hosting, AI generation) | run under your Summer account | [summerengine.com/pricing](https://summerengine.com/pricing) |
 
-A command, tool contract, or roadmap entry does not by itself mean a hosted
-service is production-ready. Managed publishing, hosting, store submission, and
-matchmaking are not promised by this package.
+Publishing to summer.games, multiplayer hosting, matchmaking and Grow are live.
 
 ## CLI reference
 
 | Command | What it does |
 |---|---|
 | `summer install [--yes]` | Download Summer Engine. Prints URL and size first; never replaces an installed engine without confirmation. |
-| `summer login` | Browser-based core Summer sign-in. |
-| `summer login --store` | Browser sign-in to the Summer store so agents can upload builds (`summer_publish_build`). |
+| `summer login` | One browser sign-in for every Summer tool: your Summer account, then the store, publishing and Grow operations in the same browser. `--no-store` skips the store step. |
+| `summer login --store` | Only the store sign-in (`store.upload_file` and the cloud operations: plans, the store, publishing and Grow). |
+| `summer whoami` | The signed-in account, its plan and credits. |
+| `summer <area> <action> [--<field> <value> …] [--input '<json>'] [--dry-run] [--idempotency-key <k>] [--wait] [--json]` | Run any operation from the shell, for example `summer assets generate-image --prompt "…"` or `summer store status --game-id <id>`. |
+| `summer ops search <words…>` / `summer ops describe <op>` | Find the operation for a job, or print one operation's input, effect and approval. Works signed out: a cloud operation shows `(needs sign-in)`. |
 | `summer logout` | Clear auth tokens. |
 | `summer config [get\|set\|unset]` | Read or update the shared non-secret `~/.summer/config.json`. |
-| `summer status` | Engine state, port, auth. |
+| `summer status [--json]` | Engine state, port, auth. |
 | `summer doctor` | Diagnose Node, login, engine, project memory, MCP. |
 | `summer plan <goal>` | Route a game-building goal into skills, MCP tools, gates, and verification. |
 | `summer memory` | Inspect project memory in `.summer`. |
 | `summer memory show <file>` | Print a project memory Markdown file. |
 | `summer run [path] [--background\|--focus] [--bin <executable>]` | Launch the engine. Agents (no TTY) launch in the background by default so the window never steals focus; `--focus` brings it to the front. `--bin` (env `SUMMER_BIN`) launches a build that is not installed. |
 | `summer open <path \| target> [--print] [--list]` | A project directory opens in the running engine. Anything else is a navigation target — `billing`, `my-games`, `mcp-guide`, `scene`, `inspector`, an intent phrase, a `res://` path — opened in the browser or sent to the editor; `--print` resolves without opening. |
-| `summer create <template> [name]` | Scaffold a project from a pinned template. |
-| `summer list templates` / `projects` | Browse. |
+| `summer create <template> [name]` | Scaffold a project from a pinned template, with an AGENTS.md for your agent (and a CLAUDE.md that imports it). |
+| `summer list templates` / `projects` | Browse. `--json` for scripts. |
 | `summer events [--follow] [--kinds <csv>] [--since <seq>] [--json]` | The engine events channel (engine 0.5.66+): newest events, or stream them live. |
 | `summer debug [issue…]` | Support-ready Markdown debug report. |
 | `summer skills list` | Show all skills (`--by-domain` groups them; the same grouping is in [`library/skills/README.md`](library/skills/README.md)). |
 | `summer skills install <name>` | Install one. |
-| `summer skills install --all --agent <agent>` / `--recommended` [`--stable-only`] | Install every skill (preview included and labelled), or only the recommended subset; `--stable-only` skips preview skills. |
+| `summer skills install --all --agent <agent>` / `--recommended` / `--assets` [`--stable-only`] | Install every skill (preview included and labelled), only the recommended subset, or only the asset skills; `--stable-only` skips preview skills. |
 | `summer tool <name> --args '<json>'` | Run any Summer tool from the shell — the same implementation the MCP tool uses. `summer tool --list` prints them all. |
-| `summer mcp [--project <path> \| --instance <id>]` | Start MCP; normally auto-binds from the agent's project directory. |
+| `summer mcp [--project <path> \| --instance <id>] [--profile <p>] [--toolsets <list>] [--surface v4\|v3]` | Start MCP; normally auto-binds from the agent's project directory. `--surface` (env `SUMMER_SURFACE`): `v4` (the default: engine tools, `summer_docs_search`, `summer_docs_read`, `summer_search` and `summer_call`) or `v3` (the 3.x tools). `--profile` (env `SUMMER_PROFILE`): `full` (every tool, the default), `engine` (engine, generation and store tools; fits the per-request tool cap of clients such as VS Code Copilot, which is 128), `assets` (generation and asset tools, no engine tools). `--toolsets` (env `SUMMER_TOOLSETS`) adds toolsets by name: `core`, `assets`, `tools`, `engine`, `ui`, `ship`, `uploads`, `apps`, `board`, `grow`, `studio`, `cloud`, `other`, or `all`. `--toolsets legacy` also lists every 3.x tool name. |
 | `summer mcp setup <agent>` | Deprecated alias of `summer setup <agent>`. |
-| `summer setup <agent> [--yes] [--force] [--recommended] [--stable-only] [--no-games]` | One shot: MCP config + all skills, preview included (`--recommended` for the subset, `--stable-only` to skip preview) + doctor. Idempotent. For most agents (not Claude Desktop, Visual Studio, Qoder, Rovo Dev, LM Studio or the legacy targets) it also adds `summer-games` (`https://mcp.summer.games/mcp`: friends, parties and messages as you) unless the same URL is already listed; you sign in once through summer.games. `--no-games` skips it. |
+| `summer setup <agent> [--yes] [--force] [--recommended] [--stable-only] [--no-games] [--profile <p>] [--assets-only] [--cli]` | One shot: MCP config + all skills, preview included (`--recommended` for the subset, `--stable-only` to skip preview) + doctor. Idempotent. `--cli` (or `--no-mcp`, 4.2.0 or newer) installs the skills and no MCP server: the agent runs `summer` commands in its shell. Inside a Summer project it also adds the Summer instructions to the project's AGENTS.md and CLAUDE.md; `--no-project-files` skips that. `--profile` writes a tool profile into the agent's MCP entry (`SUMMER_PROFILE`); `vscode-copilot` gets `engine` unless you pass `--profile full`, every other agent gets every tool. `--assets-only` is the assets path: the `assets` profile, only the asset skills, no Summer Games. For most agents (not Claude Desktop, Visual Studio, Qoder, Rovo Dev, LM Studio or the legacy targets) it also adds `summer-games` (`https://mcp.summer.games/mcp`: friends, parties and messages as you) unless the same URL is already listed; you sign in once through summer.games. `--no-games` skips it. |
 
 Agents: `claude-code`, `claude-desktop`, `codex`, `cursor`, `windsurf`, `antigravity`, `cline`, `cline-cli`, `kilo-code`, `github-copilot`, `vscode-copilot`, `visual-studio`, `copilot-jetbrains`, `opencode`, `zed`, `kiro`, `goose`, `hermes`, `trae`, `qwen-code`, `kimi-code`, `crush`, `amp`, `factory`, `junie`, `warp`, `rovo-dev`, `qoder`, `grok-build`, `mistral-vibe`, `lm-studio`. Legacy (still accepted, warn on use): `gemini`, `roo-code`. Aliases: `devin`/`devin-desktop` → `windsurf`, `agy` → `antigravity`, `droid` → `factory`, `copilot` → `github-copilot`, `vscode` → `vscode-copilot`, `kilo` → `kilo-code`, `qwen` → `qwen-code`, `kimi` → `kimi-code`. Scopes: `--scope user` (default), `--scope project`.
 
@@ -388,7 +468,7 @@ Agents: `claude-code`, `claude-desktop`, `codex`, `cursor`, `windsurf`, `antigra
 
 The library grows by PR, and CI holds the line:
 
-1. **Report a bad entry.** Open an issue quoting the prompt and the response — or, if you're an agent, file `summer_library_feedback` after a verified failure.
+1. **Report a bad entry.** Open an issue quoting the prompt and the response — or, if you're an agent, file `docs.feedback` through `summer_call` after a verified failure.
 2. **Improve or add an entry.** Add `library/<kind>/<slug>/` with a `resource.yaml` (plus `SKILL.md` for skills). Run `npm run validate:library`, regenerate with `node scripts/generate-registry/cli.ts`, and commit both. Schema, capability lint, and registry parity are enforced in CI.
 
 [`docs/DEVELOPMENT.md`](./docs/DEVELOPMENT.md) is the contributor guide; [`docs/design/CONTRACT.md`](./docs/design/CONTRACT.md) is the rulebook.
@@ -414,3 +494,4 @@ Some process skills (brainstorming, writing-plans, writing-skills, investigating
 - [Download Summer Engine](https://summerengine.com/download)
 - [Documentation](https://docs.summerengine.com)
 - [Issues](https://github.com/summerengine/summer/issues)
+- [Support](https://summer.games/support) · [Privacy policy](https://www.summerengine.com/privacy) · [Terms](https://www.summerengine.com/terms)