summer-engine 2.7.0 → 2.8.0

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,16 @@
 
 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/).
 
+## [Unreleased]
+
+### 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

@@ -2,7 +2,12 @@
 
 > **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 +16,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 +27,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 +118,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 +226,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 +244,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 +269,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 +277,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 +314,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}
+```
+
+Unlike `--headless`, that instance has a real renderer, so `save_frame()` writes an actual image. Probe API: `report()` / `save_frame()` / `dump_tree()` / `press()` / `key()` / `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.
 
-**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.
+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 +345,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 +371,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 +511,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 +530,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.

package/assets/autopilot/autopilot.gd

@@ -0,0 +1,222 @@
+# Autopilot — drives the player through a list of waypoints, saves a frame at each,
+# asserts what it saw, and exits.
+#
+# This is a starting point, not a finished test. Edit CONFIG below to match your game,
+# then add your own assertions in _check_at_waypoint(). Everything here is ordinary
+# GDScript against your real running game — there is no test framework to learn.
+#
+# Run it:
+#   bash tests/autopilot/run.sh
+# or from an agent, as a RunVerification probe (see tests/autopilot/README.md).
+
+extends "res://tests/autopilot/probe_base.gd"
+
+# ── CONFIG — edit this ────────────────────────────────────────────────────────────
+
+# Node path to the player, from the current scene root.
+const PLAYER_PATH := "Player"
+
+# Input action names from your project's Input Map. Leave an entry empty to skip it.
+const ACT_LEFT  := "move_left"
+const ACT_RIGHT := "move_right"
+const ACT_UP    := ""              # "move_forward" in 3D, "move_up" in top-down 2D
+const ACT_DOWN  := ""
+const ACT_JUMP  := "jump"
+
+# Where to walk. 2D games use x/y in pixels; 3D games use x/z in metres (y ignored).
+# Positions are WORLD positions, not offsets.
+const WAYPOINTS := [
+    Vector3(300, 0, 0),
+    Vector3(600, 0, 0),
+]
+
+# How close counts as arrived, and how long to allow per leg before giving up.
+const ARRIVE_EPSILON := 40.0
+const LEG_TIMEOUT_FRAMES := 240
+
+# ── END CONFIG ────────────────────────────────────────────────────────────────────
+
+var _player: Node = null
+var _is_3d := false
+
+
+func _ready() -> void:
+    await super._ready()
+
+    # Let the scene settle. Physics frames, not timers — timers are wall-clock and
+    # make results differ between runs and between machines.
+    for _i in 30:
+        await get_tree().physics_frame
+
+    if not _bind_player():
+        finish()
+        return
+
+    report("player_path", PLAYER_PATH)
+    report("player_class", _player.get_class())
+    report("mode", "3D" if _is_3d else "2D")
+    report("start_pos", str(_pos()))
+    dump_tree()
+    save_frame("00_start")
+
+    for i in WAYPOINTS.size():
+        var target: Vector3 = WAYPOINTS[i]
+        var arrived := await _walk_to(target)
+        report("waypoint_%d_reached" % i, arrived)
+        report("waypoint_%d_pos" % i, str(_pos()))
+        save_frame("%02d_waypoint_%d" % [i + 1, i])
+        _check_at_waypoint(i)
+        if not arrived:
+            report("failed_at_waypoint", i)
+            break
+
+    _check_at_end()
+    finish()
+
+
+# ── Your assertions go here ───────────────────────────────────────────────────────
+
+# Called after arriving at (or failing to reach) each waypoint.
+func _check_at_waypoint(index: int) -> void:
+    # Assert things that are TRUE OR FALSE, not things that are approximately a number.
+    # Hold durations are wall-clock, so exact distances drift between runs.
+    #
+    #   var hud := get_tree().current_scene.get_node_or_null("UI/HUD")
+    #   report("hud_visible_at_%d" % index, hud != null and hud.visible)
+    #   report("enemies_alive_at_%d" % index, get_tree().get_nodes_in_group("enemy").size())
+    pass
+
+
+# Called once after the last waypoint.
+func _check_at_end() -> void:
+    #   report("player_alive", _player.has_method("is_alive") and _player.is_alive())
+    pass
+
+
+# ── Machinery — you should not need to edit below this line ───────────────────────
+
+func _bind_player() -> bool:
+    var scene := get_tree().current_scene
+    if scene == null:
+        report("error", "no current scene — is run/main_scene set in project.godot?")
+        return false
+    _player = scene.get_node_or_null(PLAYER_PATH)
+    if _player == null:
+        report("error", "player not found at '%s'" % PLAYER_PATH)
+        report("scene_children", _child_names(scene))
+        dump_tree()
+        return false
+    _is_3d = _player is Node3D
+    if not (_is_3d or _player is Node2D):
+        report("error", "player at '%s' is neither Node2D nor Node3D" % PLAYER_PATH)
+        return false
+    return true
+
+
+func _child_names(n: Node) -> Array:
+    var names := []
+    for c in n.get_children():
+        names.append(c.name)
+    return names
+
+
+# Player position normalised to a Vector3 so one code path handles 2D and 3D.
+# In 2D, x/y are screen pixels and z is unused.
+func _pos() -> Vector3:
+    if _is_3d:
+        var p: Vector3 = _player.global_position
+        return p
+    var p2: Vector2 = _player.global_position
+    return Vector3(p2.x, p2.y, 0.0)
+
+
+# Distance that matters for "did we arrive", measured ONLY on axes the game can
+# actually steer. A side-on platformer has no up/down actions, so its Y is gravity,
+# not a destination — including it would mean the player never "arrives" while
+# standing on the ground 368 pixels below Y=0. That is a real failure this scaffold
+# hit on its first run.
+func _planar_distance(a: Vector3, b: Vector3) -> float:
+    var d := 0.0
+    if _has_horizontal_actions():
+        d += pow(b.x - a.x, 2.0)
+    if _has_secondary_actions():
+        var d2 := (b.z - a.z) if _is_3d else (b.y - a.y)
+        d += pow(d2, 2.0)
+    return sqrt(d)
+
+
+func _has_horizontal_actions() -> bool:
+    return _action_live(ACT_LEFT) or _action_live(ACT_RIGHT)
+
+
+func _has_secondary_actions() -> bool:
+    return _action_live(ACT_UP) or _action_live(ACT_DOWN)
+
+
+func _action_live(action: String) -> bool:
+    return action != "" and InputMap.has_action(action)
+
+
+func _walk_to(target: Vector3) -> bool:
+    var frames := 0
+    var held: Array[String] = []
+
+    while frames < LEG_TIMEOUT_FRAMES:
+        var here := _pos()
+        if _planar_distance(here, target) <= ARRIVE_EPSILON:
+            _release(held)
+            return true
+
+        var want := _actions_toward(here, target)
+        # Only touch actions that changed, so a held key stays held across frames
+        # instead of being released and re-pressed every frame.
+        for a in held:
+            if not want.has(a):
+                _set_action(a, false)
+        for a in want:
+            if not held.has(a):
+                _set_action(a, true)
+        held = want
+
+        await get_tree().physics_frame
+        frames += 1
+
+    _release(held)
+    return false
+
+
+func _actions_toward(here: Vector3, target: Vector3) -> Array[String]:
+    var out: Array[String] = []
+    var dx := target.x - here.x
+    if absf(dx) > ARRIVE_EPSILON * 0.5:
+        var a := ACT_RIGHT if dx > 0.0 else ACT_LEFT
+        if _action_live(a):
+            out.append(a)
+
+    # Second axis: z in 3D, y in 2D. Skipped when the game has no such actions
+    # (a side-on platformer, for example).
+    if _has_secondary_actions():
+        var d2 := (target.z - here.z) if _is_3d else (target.y - here.y)
+        if absf(d2) > ARRIVE_EPSILON * 0.5:
+            var b := ACT_DOWN if d2 > 0.0 else ACT_UP
+            if _action_live(b):
+                out.append(b)
+
+    return out
+
+
+# Press and release directly rather than via press(), which awaits its own hold
+# duration on the wall clock. Holding across physics frames is what makes an
+# autopilot run reproducible.
+func _set_action(action: String, pressed: bool) -> void:
+    if action == "" or not InputMap.has_action(action):
+        return
+    var ev := InputEventAction.new()
+    ev.action = action
+    ev.pressed = pressed
+    Input.parse_input_event(ev)
+
+
+func _release(held: Array) -> void:
+    for a in held:
+        _set_action(a, false)