summer-engine 2.3.0 → 2.6.0

package/skills/_tests/specs/design-npc.md

@@ -1,143 +0,0 @@
-# Skill Spec: /design-npc
-
-## Fixture
-
-- Godot 4.5 / Summer Engine project, main scene with `World/Player` (CharacterBody3D in `player` group) and an empty `World/Enemies` parent.
-- Summer MCP tools available.
-- Host file tools available (Read, Edit, Write).
-
-## Case 1: Happy Path — basic patrol-and-chase enemy with personality + intent
-
-**Input:** "Add a basic enemy that chases the player when it sees them."
-
-**Expected MCP tool sequence (in order):**
-
-1. (Skill asks the archetype question and waits.)
-2. User confirms "basic enemy".
-3. `summer_get_scene_tree`
-4. `summer_inspect_node "./World/Player"` — confirms it's in `player` group
-5. (Skill proposes the bundle: scene tree + script + personality knobs + intent enum + action SM + telegraph + loot hook + "May I create?")
-6. After user OK:
-   - `summer_add_node(parent="./World/Enemies", type="CharacterBody3D", name="Enemy")`
-   - `summer_add_node(parent="./World/Enemies/Enemy", type="CollisionShape3D", name="Body")`
-   - `summer_add_node(parent="./World/Enemies/Enemy", type="MeshInstance3D", name="Mesh")`
-   - `summer_add_node(parent="./World/Enemies/Enemy", type="Area3D", name="Vision")`
-   - `summer_add_node(parent="./World/Enemies/Enemy/Vision", type="CollisionShape3D", name="VisionShape")`
-   - `summer_add_node(parent="./World/Enemies/Enemy", type="RayCast3D", name="Sight")`
-   - (Vision SphereShape3D saved as standalone `.tres`, NOT inline)
-   - `summer_set_prop` on Sight: `enabled = true`
-   - `Write scripts/enemy_ai.gd`
-   - `summer_connect_signal(from="./World/Enemies/Enemy/Vision", signal="body_entered", to="./World/Enemies/Enemy", method="_on_body_entered")`
-   - `summer_save_scene`
-   - `summer_get_script_errors`
-
-**Assertions:**
-
-- [ ] Skill asks the archetype question before any tool call.
-- [ ] Scene has BOTH a Vision Area3D AND a Sight RayCast3D (the two-step perception pattern).
-- [ ] Vision shape is saved as a standalone `.tres`, NOT inline sub_resource (silent-fail trap).
-- [ ] Script declares four `@export_range(0.0, 1.0)` personality knobs: `aggression`, `patience`, `caution`, `punishment`.
-- [ ] Script jitters personality in `_ready` via `randf_range` clamped to `[0.0, 1.0]`.
-- [ ] Script defines an `enum Intent` with at least 5 values from {IDLE, PATROL, INVESTIGATE, HUNT, KILL, RETREAT, RESCUE_ALLY}.
-- [ ] Script defines an `enum State` with the 4 action states (CALM / ALERT / AGGRESSIVE / DEFEATED).
-- [ ] Intent layer (`_update_intent` / `_decide_intent`) computes `current_intent` from perception + personality.
-- [ ] Action SM (`_update_action`) reads `current_intent`; it does NOT write it.
-- [ ] Script has an `attack_telegraph` parameter in 0.3–0.7 sec range, scaled by aggression at attack time.
-- [ ] Script emits a `died` signal AND an `ally_defeated` signal.
-- [ ] Script uses `distance_squared_to` (NOT `distance_to`) for range comparisons.
-- [ ] Script uses typed GDScript per `_shared/gd-style.md`.
-- [ ] Skill asks "May I create / write …" before each user-visible mutation.
-- [ ] Final step is `summer_save_scene` then `summer_get_script_errors`.
-
-## Case 2: Failure Path — wave-mob archetype but user asks for full FSM
-
-**Fixture:** User wants 100+ enemies on screen at once.
-
-**Input:** "Spawn 100 enemies that chase the player. Each one should perceive, decide, telegraph attacks, and drop loot."
-
-**Expected behavior:**
-
-- Skill recognizes the scale conflict.
-- Says: "100 enemies with full intent SM + LOS perception will eat your frame budget. For wave mobs at this scale, the right archetype is the wave-mob (single KILL intent, 2 action states, no LOS). Want me to build that instead?"
-- Does NOT silently build 100 expensive enemies.
-- Offers the trade-off explicitly.
-
-**Assertions:**
-
-- [ ] Skill names the performance trade-off, not just "this is hard".
-- [ ] Skill points to the wave-mob archetype as the right answer.
-- [ ] Skill does NOT proceed without confirmation.
-- [ ] Skill never starts spawning 100 expensive nodes.
-
-## Case 3: Edge Case — boss with phases
-
-**Fixture:** Same as Case 1.
-
-**Input:** "Design a 3-phase boss for the dungeon room."
-
-**Expected behavior:**
-
-- Skill picks the **boss** archetype (different complexity budget).
-- Calls out: "Boss complexity (6–10 action states, 5–7 intents incl. RESCUE_ALLY, scripted phases) is at the threshold where a behavior tree might pay off, but I recommend a hand-coded FSM with phase enum first since you're a single dev."
-- Recommends boss personality bias: aggression 0.7–0.9, patience 0.7–0.9, punishment 0.8–1.0 (from the tunable matrix).
-- Walks all six pillars at boss scale: more tells per state, telegraph 0.5–0.7 sec, distinct mechanics per phase (cap at 4–6 total mechanics).
-- Defers to `ai-and-npcs/boss-patterns/SKILL.md` for the deeper phase-transition patterns.
-- Does NOT just scale up the basic-enemy stub.
-
-**Assertions:**
-
-- [ ] Skill recognizes "boss" requires a different design.
-- [ ] Skill caps at 4–6 distinct mechanics across phases.
-- [ ] Skill mentions phase enum as the FSM extension.
-- [ ] Skill cites boss-archetype personality ranges from the tunable matrix.
-- [ ] Skill defers to boss-patterns for deeper detail rather than trying to one-shot it.
-
-## Case 4: No Summer MCP — fallback path
-
-**Fixture:** Same as Case 1, but Summer MCP unavailable.
-
-**Input:** "Add a basic enemy that chases the player."
-
-**Expected behavior:**
-
-- Skill detects MCP unavailable.
-- Asks user to paste the existing scene tree (or relevant `.tscn` snippet) so node paths are right.
-- Generates a `.tscn` snippet (Enemy + Vision + Sight + Mesh + CollisionShape) with valid Godot 4 scene syntax.
-- Writes `scripts/enemy_ai.gd` directly with the personality + intent + action layers intact.
-- Provides manual editor instructions for connecting the `body_entered` signal.
-- Still asks "May I write …" before each file write.
-
-**Assertions:**
-
-- [ ] Skill does not blindly call `summer_*` tools and fail.
-- [ ] Generated `.tscn` is valid Godot 4 syntax (parseable).
-- [ ] Generated GDScript has personality knobs, intent enum, action SM (same structure as MCP path).
-- [ ] Skill still asks "May I" on writes.
-
-## Case 5: Group emergence — squad of 4 with varied aggression
-
-**Fixture:** Same as Case 1. User wants a small squad, not a wave.
-
-**Input:** "Spawn a patrol squad of 4 basic_grunt enemies near the gate."
-
-**Expected behavior:**
-
-- Skill picks the **basic enemy** archetype with squad framing.
-- Confirms the squad uses the **same `enemy_ai.gd` script and same archetype `.tscn`** — variation comes from per-instance personality jitter, NOT 4 different scripts.
-- Shows / verifies that `personality_jitter` (default 0.15) is set on each instance, with base aggression in the basic_grunt range (0.5–0.7).
-- Predicts the emergent roles: with jitter, post-spawn aggression values land roughly across `0.35 / 0.5 / 0.65 / 0.85` and produce a sniper / anchor / flanker / berserker mix.
-- Does NOT author per-instance roles by hand.
-- Does NOT duplicate the script per role.
-
-**Assertions:**
-
-- [ ] All 4 spawned NPCs use the same script file and same archetype scene.
-- [ ] Each instance's `_ready` jitters all 4 personality knobs via `randf_range` clamped to `[0.0, 1.0]`.
-- [ ] Skill explicitly cites group emergence (varied aggression -> varied roles) instead of authoring roles centrally.
-- [ ] Skill does NOT recommend creating `sniper_ai.gd`, `flanker_ai.gd`, etc. as separate scripts.
-- [ ] Skill calls out that two NPCs with the same base archetype will still feel different post-jitter.
-- [ ] If the user pushes back ("I want one to definitely be a sniper"), skill suggests narrowing that *instance's* base values (e.g., aggression 0.2, caution 0.8) rather than forking the script.
-
----
-
-This spec runs via `/skill-test design-npc spec` (see `_meta/skill-test/SKILL.md`).

package/skills/_tests/specs/export-and-ship.md

@@ -1,114 +0,0 @@
-# Skill Spec: /export-and-ship
-
-## Fixture
-
-- Godot 4.5 / Summer Engine project, complete game with main scene set, no script errors, basic icon at `icon.png` (256×256).
-- Existing `export_presets.cfg` with Windows/Mac/Linux presets, all `debug = true` (development defaults).
-- No `LICENSE` file at repo root.
-- No `attribution.md`.
-- Two CC-BY 4.0 assets imported from public sources (used in scene).
-- Summer MCP tools available.
-
-## Case 1: Happy Path — Steam (Windows + Mac + Linux)
-
-**Input:** "I'm ready to ship to Steam. Build me Windows, Mac, and Linux releases."
-
-**Expected MCP tool sequence (in order):**
-
-1. (Skill asks the destination question and waits — confirms Steam, Win/Mac/Linux.)
-2. Pre-flight:
-   - `summer_get_diagnostics` — clean
-   - `summer_get_console` — clean
-   - Read `project.godot` — main scene set, no version, no name
-   - Read `LICENSE` — does not exist
-   - Read `attribution.md` — does not exist
-   - Read `export_presets.cfg` — `debug = true` on all presets
-   - Grep for hardcoded paths
-3. (Skill lists the pre-flight failures: missing LICENSE, missing attribution.md, missing version, missing game name, debug=true on release presets, missing Steam-required assets like trailer + capsules.)
-4. Skill asks: "Pre-flight failed on N items: <list>. Want me to walk these one by one?"
-5. (Does NOT proceed to build.)
-
-**Assertions:**
-
-- [ ] Skill asks the destination question first.
-- [ ] Skill runs the FULL pre-flight checklist before any build.
-- [ ] Skill detects missing LICENSE and missing `attribution.md`.
-- [ ] Skill detects `debug = true` and flags it as a blocker for release.
-- [ ] Skill detects missing Steam-specific assets (capsules, trailer) and lists them.
-- [ ] Skill does NOT produce a build until the user fixes the blockers OR explicitly waives them.
-- [ ] Skill never auto-uploads to Steam Pipe — only points at the upload command.
-
-## Case 2: Failure Path — pre-flight passes, but iOS targeted without Apple Developer setup
-
-**Fixture:** Project is clean (LICENSE present, no script errors, version + name set).
-
-**Input:** "Ship to iOS App Store."
-
-**Expected behavior:**
-
-- Skill runs pre-flight — clean.
-- Skill walks iOS-specific requirements: 1024×1024 icon, screenshots at 6.5" iPhone resolution, App Store description, privacy policy URL, support URL, bundle ID, Apple Developer cert + provisioning profile.
-- Skill asks: "iOS submission requires (a) Apple Developer account ($99/yr), (b) Bundle ID configured in Apple Developer portal, (c) distribution certificate + provisioning profile, (d) macOS machine with Xcode for the final archive step. Do you have these set up? If not, those are the prerequisites — I can help with the build config but not the Apple Developer side."
-- Does NOT silently produce an unsigned `.ipa` that can't be submitted.
-
-**Assertions:**
-
-- [ ] Skill names the iOS prerequisites that aren't satisfiable from inside Godot.
-- [ ] Skill names the bundle-ID convention (`com.<org>.<game>`).
-- [ ] Skill mentions TestFlight before App Store review.
-- [ ] Skill does NOT pretend to do code signing it can't actually do.
-- [ ] Skill names AAB-vs-APK if the user mistakenly says "Android APK" (different ticket but related anti-pattern).
-
-## Case 3: Edge Case — multi-platform, web HTML5 included
-
-**Fixture:** Same as Case 1 but post-fix (LICENSE added, attribution.md added, presets `debug = false`, version = "1.0.0", screenshots ready, trailer recorded).
-
-**Input:** "Ship to Steam + itch + web."
-
-**Expected behavior:**
-
-- Pre-flight clean.
-- Skill walks each platform's requirements separately.
-- For web: explicitly flags the multiplayer transport (ENet doesn't work in browser), the audio autoplay block (Chrome blocks until first user click), and the file-size matters trap.
-- Web export preset configured: encryption disabled, no JS eval, GLES3 fallback to GLES2 on if old browsers targeted.
-- Skill asks: "May I produce 5 builds (Win + Mac + Linux + itch packages + web)?"
-- Produces builds via `godot --headless --export-release` invocations after user OK.
-- Verifies each build size and lists post-build warnings (e.g. "Web build is 180 MB — consider stripping unused textures").
-- Points at upload commands for each: `steamcmd`, `butler push`, manual itch web upload.
-
-**Assertions:**
-
-- [ ] Skill walks per-platform requirements separately, NOT a generic checklist.
-- [ ] For web: skill flags the autoplay + multiplayer + file-size traps explicitly.
-- [ ] Skill produces builds in correct order (build, then verify, then point at upload — never auto-upload).
-- [ ] Skill provides per-platform upload commands (steamcmd / butler / etc).
-- [ ] Skill does NOT execute uploads itself.
-
-## Case 4: No Summer MCP — fallback path
-
-**Fixture:** Same as Case 1, MCP unavailable.
-
-**Input:** "I want to ship to Steam."
-
-**Expected behavior:**
-
-- Skill detects MCP unavailable.
-- Asks user to confirm via the editor: main scene set, no errors in Output panel, no errors in Debugger panel.
-- Asks user to paste contents of `project.godot` and `export_presets.cfg`.
-- Walks the pre-flight checklist by reasoning over the pasted text.
-- Provides per-platform asset list and config recommendations.
-- Provides build commands the user can run manually (`godot --headless --export-release ...`).
-- Provides upload commands the user can run manually (`steamcmd ...`).
-- Still applies "May I write" before any file edit (e.g. `LICENSE` creation).
-
-**Assertions:**
-
-- [ ] Skill does not blindly call `summer_*` tools and fail.
-- [ ] Skill asks for the specific files it needs (project.godot, export_presets.cfg).
-- [ ] Skill still runs the full pre-flight check via reading.
-- [ ] Skill names the same blockers (LICENSE, debug=true, missing trailer).
-- [ ] Skill asks "May I write" before creating LICENSE / attribution.md / etc.
-
----
-
-This spec runs via `/skill-test export-and-ship spec` (see `_meta/skill-test/SKILL.md`).

package/skills/_tests/specs/fps-controller.md

@@ -1,113 +0,0 @@
-# Skill Spec: /fps-controller
-
-## Fixture
-
-- Empty Godot 4.5 / Summer Engine project, main scene open with a single `World` (Node3D) root.
-- Summer MCP tools available (engine running on localhost:6550).
-- No existing input actions in InputMap beyond Godot defaults.
-- No script files attached.
-
-## Case 1: Happy Path — fresh FPS in an empty scene
-
-**Input:** "Add a first-person controller to my scene."
-
-**Expected MCP tool sequence (in order):**
-
-1. `summer_get_scene_tree` — verify empty World exists.
-2. `summer_add_node(parent="./World", type="CharacterBody3D", name="Player")`
-3. `summer_add_node(parent="./World/Player", type="CollisionShape3D", name="Collision")`
-4. `summer_set_prop("./World/Player/Collision", "shape", "CapsuleShape3D")` (creates standalone, NOT inline sub-resource)
-5. `summer_set_resource_property("./World/Player/Collision", "shape", "radius", "0.4")`
-6. `summer_set_resource_property("./World/Player/Collision", "shape", "height", "1.8")`
-7. `summer_add_node(parent="./World/Player", type="Node3D", name="Head")`
-8. `summer_set_prop("./World/Player/Head", "position", "Vector3(0, 1.6, 0)")`
-9. `summer_add_node(parent="./World/Player/Head", type="Camera3D", name="Camera")`
-10. `summer_input_map_bind(name="move_forward", events=[{type:"key", key:"W"}])`
-11. `summer_input_map_bind(name="move_back",    events=[{type:"key", key:"S"}])`
-12. `summer_input_map_bind(name="move_left",    events=[{type:"key", key:"A"}])`
-13. `summer_input_map_bind(name="move_right",   events=[{type:"key", key:"D"}])`
-14. `summer_input_map_bind(name="jump",         events=[{type:"key", key:"Space"}])`
-15. `summer_input_map_bind(name="sprint",       events=[{type:"key", key:"Shift"}])`
-16. (User-side write) `Write` script file `scripts/player_controller.gd` after the agent asks "May I create the controller script and attach it to ./World/Player?"
-17. `summer_save_scene`
-18. `summer_get_script_errors`
-
-**Assertions:**
-
-- [ ] CharacterBody3D node exists at `./World/Player`.
-- [ ] CollisionShape3D is a child of Player with a CapsuleShape3D (NOT BoxShape, NOT SphereShape).
-- [ ] A `Head` Node3D pivots at `y ≈ 1.6` and contains the Camera3D as a child (yaw on body, pitch on head — never both on the body).
-- [ ] All 6 input actions bound: `move_forward`, `move_back`, `move_left`, `move_right`, `jump`, `sprint`.
-- [ ] Skill asks "May I create / attach …" before the script write.
-- [ ] Skill never calls `summer_set_resource_property` on an inline `sub_resource` (the silent-fail trap from `_shared/mcp-tools-reference.md`).
-- [ ] Final step is `summer_save_scene` followed by `summer_get_script_errors`.
-- [ ] Script uses typed GDScript per `_shared/gd-style.md` (`@export`, `:=`, `class_name`).
-- [ ] Script defines `coyote_time` and `jump_buffer_time` as `@export` floats with sensible defaults (0.05–0.2).
-- [ ] Script defines separate `ground_accel`, `ground_friction`, `air_accel`, `air_friction` exports — NOT a single `move_speed` snap-to-target.
-- [ ] Script implements `air_accel < ground_accel` (reduced air control, not zero, not full).
-- [ ] Script defines an `external_velocity: Vector3` accumulator AND a public `add_external_velocity(impulse: Vector3)` method.
-- [ ] Script subtracts the previous frame's external contribution at the top of `_physics_process` BEFORE applying gravity (prevents knockback compounding).
-- [ ] Script uses `move_toward` for horizontal acceleration/deceleration — not `velocity.x = direction.x * speed` snap.
-- [ ] Script applies asymmetric gravity (`fall_gravity_multiplier` when `velocity.y < 0`).
-- [ ] Mouse look pitches `Head`, not `Player`. Pitch is clamped to `[pitch_min, pitch_max]`.
-- [ ] `Input.mouse_mode = Input.MOUSE_MODE_CAPTURED` set in `_ready`.
-
-## Case 2: Failure Path — existing PlayerOld in scene
-
-**Fixture:** Same as Case 1, but `World/PlayerOld` exists with a CharacterBody3D + collision (manually authored).
-
-**Input:** "Add a first-person controller to my scene."
-
-**Expected behavior:**
-
-- Skill detects the name collision via `summer_get_scene_tree`.
-- Skill asks: "I see `World/PlayerOld` already exists. Should I replace it, add a second player as `Player2`, or something else?"
-- Does NOT silently overwrite.
-
-**Assertions:**
-
-- [ ] Skill calls `summer_get_scene_tree` before any mutation.
-- [ ] Skill asks the user how to handle the collision before adding any node.
-- [ ] No `summer_add_node` calls happen until the user answers.
-
-## Case 3: Edge Case — user says "third-person"
-
-**Fixture:** Empty Godot project, main scene with `World` only.
-
-**Input:** "Build a third-person FPS controller."
-
-**Expected behavior:**
-
-- Skill clarifies the contradiction: FPS = first-person; third-person ≠ FPS.
-- Either asks the user which they meant, OR hands off to `/tps-controller` (when that skill ships) and explains the difference.
-
-**Assertions:**
-
-- [ ] Skill does NOT silently start building a third-person controller using FPS scaffolding.
-- [ ] Skill explicitly names the ambiguity ("FPS means first-person; third-person is a separate skill").
-- [ ] Skill offers a clear next step: clarify or use the right skill.
-
-## Case 4: No Summer MCP — file-edit fallback path
-
-**Fixture:** Same as Case 1 except Summer MCP is NOT available (running in plain Cursor on a project where the engine is not connected).
-
-**Input:** "Add a first-person controller to my scene."
-
-**Expected behavior:**
-
-- Skill detects no MCP and falls back to direct file edits on `level.tscn` (or whatever main scene exists).
-- Writes a `.tscn` snippet with CharacterBody3D + CollisionShape3D + Head Node3D + Camera3D following the format in the skill's "Fallback (no MCP)" section.
-- Writes `scripts/player_controller.gd` directly via host file-write tools — same skeleton as the MCP path (coyote + buffer + air-accel + external-velocity + move_toward).
-- Edits `project.godot` to add the InputMap actions (all 6: WASD + jump + sprint).
-
-**Assertions:**
-
-- [ ] Skill identifies that MCP is unavailable (does not blindly call `summer_*` tools and fail).
-- [ ] Generated `.tscn` is syntactically valid Godot 4 scene format (parseable by Godot, includes `[gd_scene ... format=3]` header and a CapsuleShape3D sub-resource with `radius` and `height`).
-- [ ] Generated `project.godot` patch follows Godot's input action format (`input/move_forward = { "deadzone": ..., "events": [...] }`).
-- [ ] Generated script still includes coyote_time, jump_buffer_time, external_velocity, move_toward acceleration model (the fallback path is NOT a downgraded skeleton).
-- [ ] Skill still asks "May I write …" before each file write.
-
----
-
-This spec runs via `/skill-test fps-controller spec` (see `_meta/skill-test/SKILL.md`).

package/skills/_tests/specs/gdscript-patterns.md

@@ -1,19 +0,0 @@
-# Skill Spec: /gdscript-patterns
-
-> Stub spec. Expand with Happy / Failure / Edge cases. See `fps-controller.md` for the canonical format.
-
-## Fixture
-
-- TBD
-
-## Case 1: Happy Path
-
-**Input:** "<typical user prompt>"
-
-**Expected MCP tool sequence (in order):**
-
-1. TBD
-
-**Assertions:**
-
-- [ ] TBD

package/skills/_tests/specs/host-authoritative-state.md

@@ -1,104 +0,0 @@
-# Skill Spec: /host-authoritative-state
-
-## Fixture
-
-- A Godot 4.5 / Summer Engine project with `/peer-to-peer-multiplayer` Layer 1 already done — `NetworkManager` autoload exists, exposes `peer_joined` / `peer_left` signals.
-- Project may have a partial player scene; no Managers yet.
-- Summer MCP tools available; engine on localhost:6550.
-
-## Case 1: Happy Path — design HealthManager from scratch with full ownership audit
-
-**Input:** "I want to add health, damage, and a kill counter to my multiplayer game. Help me set it up correctly."
-
-**Expected behavior:**
-
-1. Skill confirms `NetworkManager` already exists; if not, defers to `/peer-to-peer-multiplayer`.
-2. Skill walks the user through the fundamental question on each new field: `health`, `max_health`, `score`, `kills`. All four → host-owned.
-3. Skill proposes one Manager per domain — `HealthManager` for health/max_health, `ScoreManager` for score/kills. Asks before creating each.
-4. For `HealthManager`, skill walks the canonical shape:
-   - Data dict keyed by `peer_id`.
-   - `_host_apply_damage()` mutator with `if not NetworkManager.is_host: return` first line.
-   - `_client_request_damage()` RPC with `@rpc("any_peer", "call_remote", "reliable")` and validation (range, line-of-sight, cooldown, magnitude).
-   - `_broadcast_health()` and `_broadcast_death()` with `@rpc("authority", "call_remote", "reliable")`.
-   - `peer_joined` registers, `peer_left` cleans up.
-5. After file write, `summer_get_script_errors` to verify clean compile.
-
-**Expected MCP tool sequence (partial):**
-
-1. `summer_get_scene_tree` — confirm NetworkManager autoload presence.
-2. `Read autoloads/network_manager.gd` — confirm signals match expected shape.
-3. (User approves HealthManager) `Write autoloads/HealthManager.gd`.
-4. `summer_get_script_errors` to verify.
-5. (User approves ScoreManager) repeat.
-
-**Assertions:**
-
-- [ ] Skill applies the fundamental question explicitly to each field — does not silently dump generic state.
-- [ ] Skill proposes one Manager per domain, not one mega-Manager for all state.
-- [ ] Every `_host_apply_*` function's first line is `if not NetworkManager.is_host: return`.
-- [ ] Every `_client_request_*` is `@rpc("any_peer", "call_remote", "reliable")` and has at least three validators.
-- [ ] Every `_broadcast_*` is `@rpc("authority", "call_remote", "reliable")`.
-- [ ] `peer_joined` and `peer_left` lifecycle is wired in `_ready()`.
-- [ ] Skill does NOT use `MultiplayerSynchronizer` for any health/score field.
-- [ ] Skill asks "May I…" before each new file creation.
-
-## Case 2: Late-join state sync
-
-**Input:** "I have HealthManager working but new players who join mid-match see 100 HP for everyone, even players who are at 30 HP. Fix it."
-
-**Expected behavior:**
-
-- Skill identifies the bug: no late-join state replay.
-- Skill explains the pattern: `_send_full_state(peer_id)` method on each Manager, called from `peer_joined`, uses `rpc_id` (flavor 4) to target only the joining peer.
-- Skill audits all existing Managers for missing `_send_full_state` and adds it.
-- Skill verifies idempotency — receiving a broadcast twice for the same peer must be a no-op.
-
-**Assertions:**
-
-- [ ] Skill diagnoses the missing late-join replay before writing code.
-- [ ] Skill uses `rpc_id(target_peer, ...)` (flavor 4), NOT a broadcast to all peers.
-- [ ] Skill audits ALL existing Managers, not just HealthManager — score, inventory, cooldowns all need the same fix.
-- [ ] Skill checks that broadcast handlers are idempotent before shipping.
-- [ ] `summer_get_script_errors` runs after each file edit.
-
-## Case 3: Edge — client wants to lie about position (client-predicted)
-
-**Input:** "A peer reports another player is teleporting around the map. I added validation to `_client_request_position()` and it blocks legitimate movement. What do I do?"
-
-**Expected behavior:**
-
-- Skill identifies the user has put `position` into the wrong column. Position is **host-authoritative with client prediction**, not pure host-owned.
-- Skill explains: clients send their input/intent (movement direction + jump), not their final position. Host runs the same physics function authoritatively. If host's computed position diverges from client's reported position by more than a tolerance, host snaps the client (reconciliation).
-- Skill removes the `_client_request_position` validator and points to `/peer-to-peer-multiplayer` Layer 4 for the prediction/reconciliation pattern.
-- Skill notes that "blocking" position requests defeats the point of prediction — it would make movement feel terrible. The right response to a divergent client is reconciliation, not rejection.
-
-**Assertions:**
-
-- [ ] Skill recognizes position is the "Sometimes" category from the fundamental question, not pure host-owned.
-- [ ] Skill defers reconciliation logic to `/peer-to-peer-multiplayer` Layer 4 instead of inventing a new pattern.
-- [ ] Skill does NOT propose validating each position update with range/distance checks — that's the wrong tool.
-- [ ] Skill explains why teleport-cheating is caught by reconciliation, not rejection.
-
-## Case 4: No Summer MCP — fallback path
-
-**Fixture:** Same as Case 1, but Summer MCP unavailable.
-
-**Input:** "Add a HealthManager autoload to my multiplayer game."
-
-**Expected behavior:**
-
-- Skill detects MCP unavailable.
-- Walks the same Manager shape (data, mutators, requests, broadcasts, lifecycle).
-- Instead of `summer_get_script_errors`, asks the user to save and check errors via the Godot editor.
-- Provides exact `[autoload]` lines for `project.godot` to paste.
-- File write still goes through `Write` host tool with "May I…" approval.
-
-**Assertions:**
-
-- [ ] Skill detects MCP unavailable; doesn't blindly call `summer_*` tools and fail.
-- [ ] `project.godot` autoload lines are provided as exact paste-able text.
-- [ ] Manager shape (5-part: data / mutators / requests / broadcasts / lifecycle) is identical regardless of MCP availability.
-
----
-
-This spec runs via `/skill-test host-authoritative-state spec` (see `_meta/skill-test/SKILL.md`).

package/skills/_tests/specs/make-game.md

@@ -1,19 +0,0 @@
-# Skill Spec: /make-game
-
-> Stub spec. Expand with Happy / Failure / Edge cases. See `fps-controller.md` for the canonical format.
-
-## Fixture
-
-- TBD
-
-## Case 1: Happy Path
-
-**Input:** "<typical user prompt>"
-
-**Expected MCP tool sequence (in order):**
-
-1. TBD
-
-**Assertions:**
-
-- [ ] TBD

package/skills/_tests/specs/peer-to-peer-multiplayer.md

@@ -1,99 +0,0 @@
-# Skill Spec: /peer-to-peer-multiplayer
-
-## Fixture
-
-- A Godot 4.5 / Summer Engine project that does NOT yet have multiplayer.
-- Project may be empty or may have an existing single-player scene.
-- Summer MCP tools available; engine running on localhost:6550.
-
-## Case 1: Happy Path — fresh multiplayer architecture from scratch
-
-**Input:** "I want to add 2-player co-op to my game. Players will connect through Steam friend invites."
-
-**Expected behavior:**
-
-1. Skill confirms P2P is the right architecture (Steam friend invite ≤8 players → P2P, not dedicated server).
-2. Skill walks the four layers in order, checkpointing between each.
-3. Layer 1: asks "May I create `autoloads/network_manager.gd`?" — creates it on user OK, calls `summer_project_setting` to register the autoload.
-4. Layer 2: asks "May I create `autoloads/game_state.gd` and walk through the authority decision matrix?" — creates it, prompts user for game-specific state fields and proposes ownership.
-5. Layer 3: explains the three RPC patterns with examples; doesn't auto-apply (this is reference material until concrete game logic exists).
-6. Layer 4: defers prediction/interpolation until there's a player scene to apply it to.
-
-**Expected MCP tool sequence (in order, partial):**
-
-1. `summer_get_scene_tree` — see what already exists.
-2. `summer_get_project_context` — read autoload list to avoid name collisions.
-3. (User approves Layer 1) `Write autoloads/network_manager.gd`.
-4. `summer_project_setting(key="autoload/NetworkManager", value="*res://autoloads/network_manager.gd")`.
-5. (User approves Layer 2) `Write autoloads/game_state.gd`.
-6. `summer_project_setting(key="autoload/GameState", value="*res://autoloads/game_state.gd")`.
-7. `summer_save_scene` and `summer_get_script_errors` to verify clean.
-
-**Assertions:**
-
-- [ ] Skill explicitly checks Step 0 (P2P vs. client-server) before any code is written.
-- [ ] Skill creates Layer 1 (NetworkManager) before Layer 2 (GameState).
-- [ ] NetworkManager is the only place that calls `multiplayer.peer_connected.connect()` directly. GameState listens to NetworkManager signals, NOT to the multiplayer API directly.
-- [ ] GameState uses `@rpc("authority", "call_remote", "reliable")` for host-broadcast functions and `@rpc("any_peer", "call_remote", "reliable")` with a `is_host` guard for client-request functions.
-- [ ] Skill walks the user through the authority decision matrix before writing GameState. Doesn't dump generic state fields without asking what the game has.
-- [ ] Skill asks "May I…" before each new file creation and before the autoload registration.
-- [ ] Skill does NOT apply prediction/interpolation in Layer 4 unless there's an existing player scene to wire into.
-- [ ] At any layer, `summer_get_script_errors` is called after the file write to confirm clean compile.
-
-## Case 2: Failure Path — user wants matchmaking at scale
-
-**Input:** "I'm building a competitive shooter. I want matchmaking with anti-cheat for 10,000 concurrent matches."
-
-**Expected behavior:**
-
-- Skill recognizes Step 0: this is dedicated client-server territory, not P2P.
-- Skill explains why P2P is wrong (host can cheat, no anti-cheat hooks, scale concerns).
-- Skill defers to `/summer:client-server-multiplayer` (when shipped) OR explains the user needs to roll a custom server.
-- Does NOT start writing P2P NetworkManager code anyway.
-
-**Assertions:**
-
-- [ ] Skill stops at Step 0 — does NOT proceed to Layer 1.
-- [ ] Skill explains the architecture mismatch in one sentence.
-- [ ] Skill names the right alternative (client-server) and which skill to use instead.
-
-## Case 3: Edge Case — retrofitting multiplayer to a single-player game
-
-**Input:** "I have a single-player platformer that's mostly done. Can you add multiplayer?"
-
-**Expected behavior:**
-
-- Skill is honest about the cost: retrofitting multiplayer is 5× harder than starting MP-first.
-- Skill asks: "Are you committed? It will require auditing every state mutation in your existing code. Time estimate: significant."
-- If user proceeds: skill walks the same 4 layers but adds an AUDIT phase before Layer 2: identify every place existing code writes to state that should be host-authoritative.
-- If user balks: skill points to alternatives (release MP as a sequel; ship single-player; add async leaderboards instead).
-
-**Assertions:**
-
-- [ ] Skill warns about retrofit cost BEFORE starting Layer 1.
-- [ ] Skill adds an AUDIT step that doesn't exist in the happy-path workflow.
-- [ ] Skill never silently proceeds as if the game were greenfield.
-
-## Case 4: No Summer MCP — fallback path
-
-**Fixture:** Same as Case 1, but Summer MCP unavailable.
-
-**Input:** "Add multiplayer to my Godot game (P2P, friend invite)."
-
-**Expected behavior:**
-
-- Skill detects MCP unavailable.
-- Walks the same 4 layers.
-- Instead of `summer_project_setting`, asks the user to manually edit `project.godot`'s `[autoload]` section — provides the exact lines to paste.
-- Instead of `summer_save_scene` / `summer_get_script_errors`, asks the user to save and check errors via the Godot editor.
-- All file writes still go through `Write` host tool with "May I…" approval per file.
-
-**Assertions:**
-
-- [ ] Skill detects MCP unavailable; doesn't blindly call `summer_*` tools and fail.
-- [ ] Project.godot edits are provided as exact paste-able lines.
-- [ ] Workflow shape (4 layers, checkpoints between) is identical regardless of MCP availability.
-
----
-
-This spec runs via `/skill-test peer-to-peer-multiplayer spec` (see `_meta/skill-test/SKILL.md`).