summer-engine 2.7.0 → 2.8.1

package/.claude-plugin/plugin.json

@@ -2,7 +2,7 @@
   "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
   "name": "summer",
   "version": "2.5.1",
-  "description": "Agent tooling for Summer Engine: game-dev skills, lifecycle hooks, and a 56-tool MCP bridge to the local desktop app.",
+  "description": "Agent tooling for Summer Engine: game-dev skills, lifecycle hooks, and a 58-tool MCP bridge to the local desktop app.",
   "author": {
     "name": "Summer Engine",
     "email": "founders@summerengine.com",
@@ -39,6 +39,7 @@
     "./skills/workflow/dispatching-parallel-agents/",
     "./skills/workflow/writing-skills/",
     "./skills/workflow/playtesting-a-feature/",
+    "./skills/workflow/headless-scripting/",
     "./skills/workflow/debugging-game-feel/",
     "./skills/workflow/diagnosing-perf-regressions/",
     "./skills/scene-and-project/brainstorm-game/",

package/.codex-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "summer",
   "version": "2.5.1",
-  "description": "Agent tooling for Summer Engine: game-dev skills, lifecycle hooks, and a 56-tool MCP bridge. Build games by talking.",
+  "description": "Agent tooling for Summer Engine: game-dev skills, lifecycle hooks, and a 62-tool MCP bridge. Build games by talking.",
   "author": {
     "name": "Summer Engine",
     "email": "founders@summerengine.com",
@@ -28,6 +28,7 @@
     "./skills/workflow/dispatching-parallel-agents/",
     "./skills/workflow/writing-skills/",
     "./skills/workflow/playtesting-a-feature/",
+    "./skills/workflow/headless-scripting/",
     "./skills/workflow/debugging-game-feel/",
     "./skills/workflow/diagnosing-perf-regressions/",
     "./skills/scene-and-project/brainstorm-game/",
@@ -95,7 +96,7 @@
   "interface": {
     "displayName": "Summer",
     "shortDescription": "Superpowers for AI game dev. Build games by talking.",
-    "longDescription": "Summer turns Codex into a game-dev studio for Summer Engine, the AI-native game engine. It adds game-dev skills, lifecycle hooks, and a 56-tool MCP bridge for guarded project files, scene editing, asset import, play mode, diagnostics, and generation. Git, shell, and grep stay with the host agent. Summer Engine is compatible with Godot 4.5. Write code in GDScript and drive project mutations through MCP. Session-start orients the session. Pre-commit doctor (opt-in) blocks bad commits.",
+    "longDescription": "Summer turns Codex into a game-dev studio for Summer Engine. Users make Summer games with the Summer SDK and GDScript. The plugin adds game-dev skills, lifecycle hooks, and a 62-tool MCP bridge for guarded project files, scene editing, asset import, play mode, diagnostics, generation, and creator workflows. Git, shell, and grep stay with the host agent. Summer follows its upstream technical base continuously; version-sensitive work uses the bundled compatibility reference instead of a fixed onboarding version. Session-start orients the session. Pre-commit doctor (opt-in) blocks bad commits.",
     "developerName": "Summer Engine",
     "category": "Coding",
     "capabilities": ["Interactive", "Read", "Write"],

package/.cursor-plugin/plugin.json

@@ -3,7 +3,7 @@
   "name": "summer",
   "displayName": "Summer",
   "version": "2.5.1",
-  "description": "Agent tooling for Summer Engine: game-dev skills, lifecycle hooks, and a 56-tool MCP bridge to the local desktop app.",
+  "description": "Agent tooling for Summer Engine: game-dev skills, lifecycle hooks, and a 58-tool MCP bridge to the local desktop app.",
   "author": { "name": "Summer Engine", "email": "founders@summerengine.com" },
   "publisher": "summer-engine",
   "homepage": "https://summerengine.com",
@@ -30,6 +30,7 @@
     "./skills/workflow/dispatching-parallel-agents/",
     "./skills/workflow/writing-skills/",
     "./skills/workflow/playtesting-a-feature/",
+    "./skills/workflow/headless-scripting/",
     "./skills/workflow/debugging-game-feel/",
     "./skills/workflow/diagnosing-perf-regressions/",
     "./skills/scene-and-project/brainstorm-game/",

package/.opencode/INSTALL.md

@@ -30,7 +30,7 @@ Restart OpenCode. The orientation banner ("Summer Engine is loaded. N skills ava
 
 ## What this gives you
 
-- **24 auto-trigger skills** under the `summer:` namespace, including `using-summer`, `brainstorm-game`, `debug`, `play`, `fps-controller`, `gdscript-patterns`, `scene-composition`, `art-direction`, and more.
+- **Summer skills** under the `summer:` namespace, including `using-summer`, `brainstorm-game`, `debug`, `play`, `fps-controller`, `gdscript-patterns`, `scene-composition`, `art-direction`, and more.
 - **A `summer-engine` MCP server** — start it with `npx summer-engine mcp` and OpenCode will route scene/diagnostics/asset tools to your local Summer Engine running on `localhost:6550`.
 - **Session-start orientation** — first user message of every session is prefixed with the using-summer primer so the model invokes skills before responding.
 

package/.opencode/plugins/summer.js

@@ -12,7 +12,7 @@ const __dirname = path.dirname(fileURLToPath(import.meta.url));
 const skillsDir = path.resolve(__dirname, '../../skills');
 
 const ORIENTATION = `<EXTREMELY_IMPORTANT>
-Summer is loaded. 24 skills available under the summer: namespace.
+Summer is loaded. Summer skills are available under the summer: namespace.
 
 Activate summer:using-summer FIRST in any Summer Engine session — it sets workflow priority and the red-flag list.
 

package/AGENTS.md

@@ -4,7 +4,7 @@ This file is for any AI agent that loads context from `AGENTS.md` (Codex CLI, Fa
 
 ## What you're working with
 
-**Summer Engine** is the AI-native game engine the user is building in. Editor, scene graph, asset pipeline, and runtime are all instrumented for programmatic control via the `summer-engine` MCP server. Summer Engine is compatible with Godot 4.5 — projects use GDScript (`.gd`), C# (`.cs`), scenes (`.tscn`/`.scn`), and resources (`.tres`/`.res`). Write code in those languages; talk to the engine through MCP tools.
+**Summer Engine** is the AI-native game engine the user is building in. The user is making a **Summer game** with the **Summer SDK**, normally in GDScript. The editor, scene graph, asset pipeline, and runtime are instrumented for programmatic control through the `summer-engine` MCP server. Summer currently uses the 4.6.1 upstream technical base, plans to adopt 4.7.1 next, and follows upstream continuously. Those numbers are compatibility facts, not the product identity. Projects use GDScript (`.gd`), C# (`.cs`), scenes (`.tscn`/`.scn`), resources (`.tres`/`.res`), and the technical `project.godot` filename.
 
 ## Critical rules
 
@@ -23,9 +23,9 @@ This file is for any AI agent that loads context from `AGENTS.md` (Codex CLI, Fa
 - **Discipline** (`gdscript-patterns`, `scene-composition`, `art-direction`) → how to shape it.
 - **Build** (`fps-controller`, `design-mechanic`, `design-level`, `setup-multiplayer`, `vfx`, `tune-performance`, `export-and-ship`) → produce the artifact.
 
-## MCP tool palette (engine on `localhost:6550`)
+## MCP tool palette (project-matched local editor)
 
-56 tools total. Categories:
+The current MCP registry is grouped into these categories:
 
 - Scene: `summer_get_scene_tree`, `summer_open_scene`, `summer_create_scene`, `summer_add_node`, `summer_set_prop`, `summer_set_resource_property`, `summer_remove_node`, `summer_save_scene`, `summer_instantiate_scene`, `summer_replace_node`, `summer_select_node`, `summer_inspect_node`, `summer_inspect_resource`, `summer_connect_signal`, `summer_batch`.
 - Diagnostics: `summer_create_debug_report`, `summer_get_script_errors`, `summer_get_diagnostics`, `summer_get_console`, `summer_clear_console`, `summer_get_debugger_errors`, `summer_get_debugger_warnings`.
@@ -41,7 +41,7 @@ Git, shell, and grep are not exposed. Project file reads and writes are exposed
 
 ## Type-system gotchas
 
-`SetProp` values are engine-formatted strings (Godot type-system compatible), not JSON objects:
+`SetProp` values are Summer Engine variant strings, not JSON objects:
 - `"Vector3(0, 10, 0)"`
 - `"Color(1, 0.5, 0, 1)"` (RGBA, 4 components)
 - `"Transform3D(1,0,0, 0,1,0, 0,0,1, 0,5,0)"`

package/CHANGELOG.md

@@ -2,6 +2,34 @@
 
 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/).
 
+## [2.8.1] — 2026-08-18 — "Scene mutations work again on engine 0.5.60+"
+
+### Added
+- `summer_get_scene_tree` accepts optional `depth` and `limit` params (engine defaults: depth 2, limit 200 — a 102-node scene silently truncated to 61 nodes at the defaults). The engine only honors them on scene-targeted reads, so the tool resolves the current scene path first when needed and says so when it can't. `summer_get_project_context` accepts an optional `settingsPrefix` and, without one, trims `project.data.entries` to a curated prefix set (application/, display/, input/, physics/, rendering/) instead of returning the full ~188KB settings dump — the payload declares the trim via `settingsTruncated`/`totalSettings`/`settingsHint`.
+- `summer_screenshot` scene captures accept `nodePath` (frame a specific node, honest `node_not_found` failure) and new framing directions `back`/`left`/`right`; captions report the resolved framing and any render retries. Requires engine 0.5.62+ to take effect — older engines silently ignore the new fields.
+- `summer_get_diagnostics` returns a prioritized bounded view (errors first, then warnings, capped info tail) with honest suppression counters, plus `includeAll: true` for the untrimmed payload. Severity + recency + caps only — no noise-pattern matching.
+- `scripts/compat-smoke.sh`: a latest-MCP × candidate-engine release gate that drives the real built MCP server against a live engine and fails loudly on batch-contract incompatibilities (the class of bug that broke 2.7.0–2.8.0 × engine 0.5.60+). Run it before every engine release and every npm publish.
+
+### Fixed
+- `summer_create_scene` no longer uses the destructive temporary-template strategy (open current scene → delete its children → save-as → restore). It now writes a minimal `.tscn` through the identity-bound engine `WriteFile` with a create-only guard, never touches the open scene, verifies by reading the file back, and gained a `rootType` param (Node3D/Node2D/Control). `allow_temporary_scene_mutation` remains accepted as a deprecated no-op.
+- **Scene mutations were completely broken against engine 0.5.60/0.5.61.** The engine now requires `SaveScene`, `InstantiateScene`, `ReplaceNode`, `SimulateInput`, and the `Run*`/`Import*`/`Git*` ops to travel as their own single-op request, and rejects any multi-op batch containing one of them wholesale (`failure_reason: "unsupported_transport"`). Since 2.7.0 appended `SaveScene` to every mutation batch, every `summer_add_node`/`summer_set_prop`/`summer_batch`/`summer_create_scene` call was rejected before anything executed. Mutation batches are now automatically split into sequential requests around single-only ops; all receipts are preserved and merged, and a mutation that applied followed by a save that failed is reported honestly (including which ops already applied and which were not sent).
+- Engine failures no longer hide the precise rejection. `extractOpError` previously returned a generic `"Engine operation failed (terminalState: failed)"` without inspecting `results[]`; it now surfaces the failed op's own error and `failure_reason` (envelope or per-op, either spelling), rendered as JSON when a classifier is present so agents can key on `failure_reason` reliably.
+- `save_frame` is documented with its required `name` argument everywhere (`save_frame()` with no args is a probe script error), plus the deferred scene-mount pattern that avoids black frames.
+- SimulateInput guidance corrected: it IS reachable over MCP/CLI as a single op against the running game (`failure_reason: "not_running"`/`"unsupported"` are the real failure modes); `"unsupported_transport"` only means it was batched with other ops. The previous claim that it needs the in-editor bridge on every build was stale.
+- The scene-preview synthetic-camera note no longer claims the scene has no camera — the engine always synthesizes the preview camera; `sceneHasCamera` is the authoritative signal and keeps its own warning.
+- `summer login` waits 15 minutes on one session id (was 2) with periodic reminders, covering first-time account creation + email confirmation. The gateway never expires a pending session, so the single id stays valid the whole window.
+- Removed the stale "Engine mirror only" banner from the README (it shipped to npm and the public repo, and its claims were wrong).
+
+## [2.8.0] — 2026-08-17 — "Multi-editor MCP routing"
+
+### Added
+- MCP discovers every live Summer editor through `~/.summer/instances/` and automatically binds local tools to the editor whose project contains the agent's current working directory.
+- `summer mcp --project <path>` and `summer mcp --instance <id>` provide explicit selection for hosts that do not start the MCP server from a project directory.
+
+### Changed
+- Multiple live editors are now a fail-closed state when no project can be inferred. MCP lists the non-secret project/instance choices instead of following the machine-global last-opened editor pointer.
+- Selected MCP sessions keep following the same project across editor restarts and validate registry identity against `/api/health` before connecting.
+
 ## [2.7.0] — 2026-07-24 — "Reliable project mutations"
 
 ### Added

package/GEMINI.md

@@ -4,7 +4,7 @@ Summer is the AI game-dev studio for **Summer Engine** — the AI-native game en
 
 ## What Summer Engine is
 
-A game engine designed for AI agents — editor, scene graph, asset pipeline, and runtime are all instrumented for programmatic control via MCP. Summer Engine is compatible with Godot 4.5: projects use GDScript (`.gd`), C# (`.cs`), scenes (`.tscn`/`.scn`), and resources (`.tres`/`.res`). Write code in those languages; talk to the engine through `summer_*` tools.
+Summer Engine is designed for AI-assisted creation. The user is making a **Summer game** with the **Summer SDK**, normally in GDScript. The editor, scene graph, asset pipeline, and runtime are instrumented for programmatic control via MCP. Summer currently uses the 4.6.1 upstream technical base, plans to adopt 4.7.1 next, and follows upstream continuously. Those numbers are compatibility facts, not the product identity. Projects use GDScript (`.gd`), C# (`.cs`), scenes (`.tscn`/`.scn`), resources (`.tres`/`.res`), and the technical `project.godot` filename.
 
 ## How to behave
 
@@ -18,9 +18,9 @@ The single most important skill to know is `summer:using-summer` — it explains
 2. **Discipline skills second**: `gdscript-patterns`, `scene-composition`, `art-direction`, `audio-direction`. These shape content.
 3. **Build skills third**: `fps-controller`, `design-mechanic`, `design-level`, `setup-multiplayer`, `vfx`, `tune-performance`, `export-and-ship`.
 
-## MCP tools (when the engine is running on `localhost:6550`)
+## MCP tools (when the project-matched local editor is running)
 
-The `summer-engine` MCP server exposes 56 focused tools. The most important:
+The `summer-engine` MCP server exposes a focused tool registry. The most important:
 
 - **Scene mutation**: `summer_add_node`, `summer_set_prop`, `summer_set_resource_property`, `summer_remove_node`, `summer_save_scene`, `summer_replace_node`, `summer_batch`. Every scene mutation requires the exact `res://...tscn` `scenePath`; opening a scene is a user-visible UI action, not a mutation prerequisite. Mutation tools append one final `SaveScene`; raw engine batches must do the same.
 - **Scene inspection**: `summer_get_scene_tree`, `summer_inspect_node`, `summer_inspect_resource`.
@@ -35,7 +35,8 @@ Git, shell, and grep remain host-native. Use the Summer file tools for project r
 
 ## Type-system traps
 
-`SetProp` values are engine-formatted **strings** (Godot 4.5 type-system compatible):
+`SetProp` values are engine-formatted **strings** compatible with the current
+Summer Engine type system:
 
 - `"Vector3(0, 10, 0)"` — NOT `{x: 0, y: 10, z: 0}`.
 - `"Color(1, 0.5, 0, 1)"` — RGBA, 4 components.

package/README.md

@@ -1,8 +1,11 @@
 # Summer Engine: the AI game engine
 
-> **Engine mirror only.** This directory is intentionally marked `private` and must never be published to npm. Review and reconcile changes into [SummerEngine/summer-engine-agent](https://github.com/SummerEngine/summer-engine-agent), which is the only npm release source.
-
-Build real 2D and 3D games through conversation. No coding required. Export to Steam, desktop, mobile, and web. Built on the Godot team's work, customized and honed so AI agents and humans can collaborate on great games.
+Build real 2D and 3D Summer games with Summer Engine, the Summer SDK, and
+GDScript. The agent layer can help author code and scenes, but creators remain
+in control of changes and release decisions. Local export support depends on
+the templates present in the installed engine. The package does not silently
+build, host, or submit games to stores; its explicit, confirmed creator command
+can publish an already-exported Summer `.pck` to Summercraft for review.
 
 **Summer** is the MIT open-source agent layer that connects your AI coding agent to Summer Engine. It is the **Summer CLI**, the **Summer MCP** server, and the **Summer agent** skills, hooks, and plugin manifests, all in one package. First-class setup works in Claude Code, Cursor, Codex, Devin Desktop (formerly Windsurf), Cline, Roo Code, Gemini CLI, GitHub Copilot CLI, GitHub Copilot in VS Code, and OpenCode. Factory Droid uses the plugin marketplace path.
 
@@ -11,7 +14,9 @@ Build real 2D and 3D games through conversation. No coding required. Export to S
 - **MCP setup:** [www.summerengine.com/mcp](https://www.summerengine.com/mcp)
 - **Docs:** [docs.summerengine.com](https://docs.summerengine.com)
 
-It just works. Open your agent, say *"let's make an FPS in Summer Engine,"* and it does.
+Once setup checks pass, open your agent and say *"let's make an FPS in Summer
+Engine."* The agent can then use the Summer SDK and local editor tools to build
+and verify the project.
 
 ---
 
@@ -20,10 +25,11 @@ It just works. Open your agent, say *"let's make an FPS in Summer Engine,"* and
 Three names, one npm package (`summer-engine`):
 
 - **Summer CLI** (`npx -y summer-engine@latest`): installs the engine, signs you in, scaffolds and runs projects, and writes your agent's config. See [www.summerengine.com/cli](https://www.summerengine.com/cli).
-- **Summer MCP**: the local MCP server that gives your agent 56 engine tools to build, run, and debug a real game. See [www.summerengine.com/mcp](https://www.summerengine.com/mcp).
+- **Summer MCP**: the local MCP server that gives your agent 58 engine tools to build, run, and debug a real game. See [www.summerengine.com/mcp](https://www.summerengine.com/mcp).
 - **Summer agent layer**: the game-dev skills, hooks, and plugin manifests that give your AI agent judgment, not just a chat box.
 
-All MIT, all free to use. One paste sets up all three.
+The CLI, MCP bridge, and agent layer are MIT licensed. The Summer Engine app has
+its own license. One setup flow wires the pieces together.
 
 ## Get started: one prompt
 
@@ -110,7 +116,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 auth callback, writes the token to `~/.summer/auth-token`, and returns. **If the user takes longer than 120 seconds, re-run `npx -y summer-engine@latest login` and tell them to come back to the terminal quickly.** Don't loop indefinitely. The same token is shared with the engine; they sign in once, both surfaces accept it.
+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 auth callback, validates that the returned identity matches the CLI token, writes the core-compatible session to the secured `~/.summer/` store, and returns. **If the user takes longer than 120 seconds, re-run `npx -y summer-engine@latest login` and tell them to come back to the terminal quickly.** Don't loop indefinitely. The same `auth-token` and `user.json` filenames remain shared with the engine; they sign in once, both surfaces accept it.
 
 ### Step 4: Re-run doctor to confirm
 
@@ -218,8 +224,9 @@ We tell you before we touch your disk.
 | `summer-engine` npm package (CLI + plugin source) | ~3 MB | 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` |
+| Creator token | ~50 bytes | only when you run `summer login --creator` and mint one | One-time browser value to `~/.summer/creator-token`; never replaces the auth token |
 | Skill files | < 50 KB | bundled in the npm package | no extra network call |
-| Generated assets (3D / image / audio / video) | varies | only on explicit `summer_generate_*` calls | Summer Engine Studio |
+| 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 |
 | URL imports | varies | only on explicit `summer_import_from_url` calls | the URL you provide |
 
 Not downloaded:
@@ -235,9 +242,14 @@ Not downloaded:
 |---|---|---|
 | **Summer** (this repo: CLI, MCP server, skills, hooks, plugin manifests) | **MIT** | [SummerEngine/summer-engine-agent](https://github.com/SummerEngine/summer-engine-agent) |
 | **Summer Engine app** (the desktop editor and runtime) | free to download, closed source for now | [summerengine.com/download](https://summerengine.com/download) |
-| **Hosted Summer AI and cloud services** (asset generation, storage, multiplayer, orchestration) | paid Summer services | [summerengine.com/pricing](https://summerengine.com/pricing) |
+| **Hosted Summer integrations** | availability and terms vary by rollout; preview features are labeled in the CLI | [summerengine.com/pricing](https://summerengine.com/pricing) |
 
-The desktop app is free to download. The AI-agent layer, meaning the CLI, MCP server, skills, and plugin manifests, is MIT open source. Hosted Summer AI, asset generation, storage, multiplayer, and cloud features are paid Summer services.
+The desktop app is free to download. The AI-agent layer, meaning the CLI, MCP
+server, skills, and plugin manifests, is MIT open source. A command, tool
+contract, or roadmap entry does not by itself mean a hosted service is
+production-ready. Summer Cloud is explicitly a research preview, and managed
+publishing, hosting, store submission, and matchmaking are not promised by this
+package.
 
 ---
 
@@ -255,7 +267,7 @@ Two pieces, plus the glue.
 
 Skills don't list steps. They encode the **order of operations**: diagnose before editing, scope before building, ask before guessing. [Agent Skills](https://agentskills.io) format, so any conformant tool picks them up.
 
-**MCP bridge.** The `summer-engine` MCP server gives the agent 56 tools that talk to your local engine on `localhost:6550`:
+**MCP bridge.** The `summer-engine` MCP server gives the agent 62 tools. Local project tools connect to the matching live editor on its loopback port; cloud and creator tools use their documented remote or local configuration contracts without requiring the editor:
 
 | | |
 |---|---|
@@ -263,13 +275,21 @@ Skills don't list steps. They encode the **order of operations**: diagnose befor
 | Diagnostics | `summer_create_debug_report`, `summer_get_script_errors`, `summer_get_diagnostics`, `summer_get_console`, `summer_clear_console`, `summer_get_debugger_errors`, `summer_get_debugger_warnings` |
 | Runtime | `summer_play`, `summer_stop`, `summer_is_running` |
 | Visual | `summer_screenshot` (see the editor viewport, an offscreen scene render, or the running game) |
-| Interactive | `SimulateInput` / `RunVerification` raw ops via `summer_batch` — drive the running game or run a hidden GDScript probe (engine-build dependent) |
+| Interactive | `RunVerification` raw op via `summer_batch` — a hidden GDScript probe that presses real inputs, saves rendered frames, and asserts. `SimulateInput` is editor-bridge only and not reachable from MCP. |
 | Project | `summer_get_project_context`, `summer_open_main_scene`, `summer_project_setting`, `summer_input_map_bind` |
 | Files | `summer_read_file`, `summer_write_file`, `summer_replace_text` — identity-bound, create-only or sha256-guarded mutations |
 | Assets | `summer_search_assets`, `summer_import_asset`, `summer_import_from_url`, `summer_generate_image`, `summer_generate_3d`, `summer_generate_audio`, `summer_generate_video` |
+| Creator | `summer_creator_publish`, `summer_creator_releases`, `summer_creator_logs`, `summer_creator_config` — confirmed immutable publish and real release history through `summer.creator.v1`, explicit unsupported logs, and shared non-secret configuration. |
 
 Git, shell, and grep remain host-native. Project file reads and writes use Summer's identity-bound tools so compatible engine builds can reject wrong-project and stale-content mutations. A host agent can still bypass these safeguards with its own file tools; the package cannot technically intercept that external process.
 
+When several Summer editors are open, MCP automatically selects the one whose
+project contains the agent's current working directory. Normal agent configs do
+not need a path or one MCP entry per editor. Hosts that launch MCP outside a
+project can use `summer mcp --project <path>`; `--instance <id>` is available
+when two editors intentionally show the same project. An ambiguous unscoped
+connection is rejected rather than routed to the last editor that opened.
+
 **Lifecycle hooks.** A `session-start` hook detects whether you're in a Summer Engine project and feeds the agent a one-line orientation. An opt-in `pre-commit doctor` runs `summer doctor` before `git commit` and blocks when the setup needs attention.
 
 For the full architecture, see [docs/OVERVIEW.md](docs/OVERVIEW.md).
@@ -292,13 +312,21 @@ summer_clear_console            # clean slate
 summer_play                     # boot the game (or a specific scene)
 summer_get_debugger_errors      # runtime errors: null refs, missing nodes, physics
 summer_screenshot target:game   # optional: look at the live frame
-summer_stop                     # ALWAYS stop — scene edits are refused while running
+summer_stop                     # stop when runtime checks are done
+```
+
+**4. Does the interaction work?** To prove input-driven behavior (jump/move/shoot), use `RunVerification` — a raw op through `summer_batch`. It spawns a hidden, disposable game instance that runs your GDScript probe, presses real inputs, reads state back across frames, saves rendered frames, and dies without ever touching the editor:
+
+```
+summer_batch ops:[{op:"RunVerification", probe_source:"…", max_seconds:20}]
+                                      → {ok, results, frames, out_dir}
 ```
 
-**4. Does the interaction work?** To prove input-driven behavior (jump/move/shoot), send a raw op through `summer_batch` (engine-build dependent — a `failure_reason:"unsupported"` comes back verbatim on older builds):
-- `SimulateInput` — inject into the **running** game: `summer_batch ops:[{op:"SimulateInput", type:"action", action:"jump", pressed:true}]`, then re-check screenshot/debugger.
-- `RunVerification` — spawn a hidden, disposable game instance that runs a GDScript probe (press inputs, read state, save frames) and dies, never touching the editor: `summer_batch ops:[{op:"RunVerification", probe_source:"…", max_seconds:20}]` → `{ok, results, frames, out_dir}`.
-- If neither is available on this build, **ask the user to try it** and report what they see — don't fake it.
+Unlike `--headless`, that instance has a real renderer, so `save_frame("name")` writes an actual image (the name argument is required). Probe API: `report(name, value)` / `save_frame(name)` / `dump_tree()` / `press(action)` / `key(keycode)` / `finish()`. **`press()` and `key()` are coroutines — `await` them.** Every project scaffolded by `summer create` ships a working example at `tests/autopilot/`.
+
+`SimulateInput` is **not** reachable from MCP or the CLI, on any build. It needs the in-editor chat bridge's async reply channel; every queued caller is answered `{ok:false, failure_reason:"unsupported_transport"}`. Use the probe.
+
+Ask the user to play only for what a probe cannot hold an opinion about: whether it *feels* right, whether it *looks* good, whether it is fun. "I can't simulate input" is not on that list.
 
 **Honesty.** Never describe an image you didn't receive; a failed capture is a *result* — report it and climb down (`scene`→`viewport`) or ask the user. Pass structured failures (`failure_reason`, `terminalState`, `identity_mismatch`) through verbatim. `summer_get_project_context` binds the session to the open project; a `projectMismatch` warning on a screenshot means the engine switched projects and the frame may be from the wrong one — rebind before trusting it.
 
@@ -315,7 +343,9 @@ summer_stop                     # ALWAYS stop — scene edits are refused while
 5. **gdscript-patterns** guides every `.gd` write.
 6. **play** runs the game and reports clean or broken.
 7. **debug** runs the cheapest diagnostic, forms one specific hypothesis, asks before editing, re-verifies after the fix.
-8. **export-and-ship** runs the pre-flight checklist before producing a release build.
+8. **export-and-ship** inventories installed export templates, runs pre-flight,
+   and produces only supported local builds after approval. It does not upload,
+   host, publish, or submit them.
 
 The skill bundle replaces "agent flailing through tutorials" with measurable craft.
 
@@ -339,7 +369,9 @@ The skill bundle replaces "agent flailing through tutorials" with measurable cra
 
 **Skill authoring**: `skill-create`, `skill-improve`, `skill-test`
 
-C# is supported by the engine. A `summer:csharp-patterns` skill is on the roadmap; for now write C# from Godot 4.5 docs.
+C# is supported by the engine. A `summer:csharp-patterns` skill is on the
+roadmap; for now use the upstream C# API reference matching the current Summer
+technical base.
 
 Full list of shipping skills: the `skills:` array in [`.claude-plugin/plugin.json`](./.claude-plugin/plugin.json).
 
@@ -477,8 +509,13 @@ npx -y summer-engine@latest doctor
 | Command | What it does |
 |---|---|
 | `summer install` | Download Summer Engine. Prints URL and size first. |
-| `summer login` | Browser-based sign-in. |
+| `summer login` | Browser-based core Summer sign-in. |
+| `summer login --creator` | Open Summercraft token settings and securely connect a separate publish-scoped creator token. |
 | `summer logout` | Clear auth tokens. |
+| `summer config [get\|set\|unset]` | Read or update the shared non-secret `~/.summer/config.json`. |
+| `summer publish [project] --artifact <game.pck> --version <value> [--confirm]` | Compute and show the exact immutable target; after approval, stream it through prepare → write-once PUT → finalize. |
+| `summer releases [--cursor <value>]` | List real creator-owned release history. |
+| `summer logs` | Read creator runtime logs. Fails closed while no durable runtime-log source exists. |
 | `summer status` | 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. |
@@ -491,7 +528,7 @@ npx -y summer-engine@latest doctor
 | `summer skills list` | Show all skills. |
 | `summer skills install <name>` | Install one. |
 | `summer skills install --recommended --agent <agent>` | Install the recommended set. |
-| `summer mcp` | Start the MCP server. |
+| `summer mcp [--project <path> \| --instance <id>]` | Start MCP; normally auto-binds from the agent's project directory. |
 | `summer mcp setup <agent>` | Write MCP config for an agent. |
 | `summer setup <agent> [--yes]` | One shot: MCP config + recommended skills + doctor. |
 

package/assets/autopilot/README.md

@@ -0,0 +1,51 @@
+# tests/autopilot
+
+A starting point for proving your game actually works — not that it compiles, that it *works*.
+
+`autopilot.gd` boots your game in an invisible instance, presses your real input actions to walk the player through a list of waypoints, saves a rendered frame at each one, records what it found, and exits. It is ordinary GDScript against your real running game. There is no test framework here to learn.
+
+## Run it
+
+```bash
+bash tests/autopilot/run.sh
+```
+
+No editor needed. Exit code is 0 when the probe finished cleanly and the engine logged no errors.
+
+Results land in `tests/autopilot/out/`:
+
+```
+results.json     reports, frame list, errors_seen, duration_ms, finished
+00_start.jpg     a real rendered frame, one per waypoint
+engine.log       full engine output if something went wrong
+```
+
+An agent can also run the same probe through MCP without touching your editor:
+
+```
+summer_batch ops:[{"op": "RunVerification",
+                   "probe_source": "<contents of autopilot.gd>",
+                   "max_seconds": 40}]
+```
+
+## Make it yours
+
+Open `autopilot.gd` and edit the `CONFIG` block at the top: the player's node path, your Input Map action names, and the waypoints to walk. Then put your real assertions in `_check_at_waypoint()` and `_check_at_end()` — the shipped version walks and looks, but asserts nothing about *your* game, and a test that asserts nothing always passes.
+
+Leave `ACT_UP` / `ACT_DOWN` empty for a side-on platformer. The autopilot then measures arrival on X alone, because in a side-scroller Y is gravity, not a destination.
+
+## Rules that will bite you otherwise
+
+**Assert inequalities, not exact numbers.** `position.x > start.x + 50` is a real assertion. `position.x == 250.0` is a flaky test you wrote yourself — hold durations resolve on the wall clock, so the same walk lands a few pixels apart between runs.
+
+**Wait on `physics_frame`, not timers.** `await get_tree().physics_frame` is reproducible; `await get_tree().create_timer(1.0).timeout` is not.
+
+**The global RNG is not seeded.** Anything downstream of `randf()` differs every run. Assert ranges, or seed it yourself at the top of the probe.
+
+**`finished: false` is a failure.** It means the probe hit `--summer-verify-max` before calling `finish()`. `run.sh` exits non-zero on it; do not read the partial reports as a pass.
+
+**Never add `--headless` to this.** Headless has no renderer: `save_frame()` gets a null image, and `draw_calls` reads 0.0 forever. The verify instance is windowed but positioned off-screen, which is why it can produce real frames and stay invisible.
+
+## Frames are the point
+
+A saved frame sequence is a flipbook of your feature happening. It is the difference between "the code path executed" and "the thing the player was promised appeared on screen". Save one wherever you would otherwise have asked a human to look.