summer-engine 3.4.0 → 3.5.0

package/library/skills/use-widget-asset/SKILL.md

@@ -108,12 +108,12 @@ extends TextureProgressBar
 
 func _ready():
     var tex = load(slice_url)
-    # The base / "under" texture is the same image — Godot will mask it
+    # The base / "under" texture is the same image — the bar masks it
     # to whatever value 0-100 we set.
     texture_under  = tex
     texture_progress = tex
     fill_mode = TextureProgressBar.FILL_LEFT_TO_RIGHT if orientation == "horizontal" else TextureProgressBar.FILL_TOP_TO_BOTTOM
-    # The fill rect tells Godot which sub-region of the texture is the
+    # The fill rect tells the bar which sub-region of the texture is the
     # bar fill (vs the frame). Texture_progress_offset + stretch_margin_*
     # form the inset.
     var sw = tex.get_width()
@@ -160,7 +160,7 @@ In the pack, find the pair: `sliceMeta[currentIndex].pairWith` gives the other s
 
 ## Cut-offs and re-renders
 
-If the detected `frameMargins` are obviously wrong (the dashed overlay in the wizard's lightbox shows the center area clipping into a corner ornament), the user should hit **Recreate (HD)** on that slice. FLUX will regenerate it cleanly — but the *margins themselves* don't get re-detected after upscale. Margins live on the original detection. The user can also manually edit them in code via the `patch_margin_*` properties after instantiating.
+If the detected `frameMargins` are obviously wrong (the dashed overlay in the wizard's lightbox shows the center area clipping into a corner ornament), the user should hit **Recreate (HD)** on that slice. It regenerates cleanly — but the *margins themselves* don't get re-detected after upscale. Margins live on the original detection. The user can also manually edit them in code via the `patch_margin_*` properties after instantiating.
 
 ## Composite panels with sub-elements
 
@@ -171,16 +171,16 @@ When a slice has `parentSliceIndex` set, it came from a **Break-down** pass —
 
 Pick based on whether your game needs the panel to stretch as one unit or whether each control needs independent interaction.
 
-See **Composite Panels (Sliced Further)** below for the canonical fields the wizard now emits (`isComposite`, `zOrder`) and the consume recipe.
+See **Composite Panels (Sliced Further)** below for the fields the wizard emits (`isComposite`, `zOrder`) and the consume recipe.
 
 ## Composite Panels (Sliced Further)
 
-The wizard's Break-down pass produces two new per-slice fields the runtime must understand:
+The wizard's Break-down pass adds per-slice fields the runtime must understand:
 
 | Field | Type | Meaning |
 |---|---|---|
 | `isComposite` | boolean | True on the **parent** slice — the flat preview image of the assembled panel. NOT a runtime asset. Filter it out on import unless the caller explicitly wants the preview thumbnail. |
-| `zOrder` | number | Back-to-front paint order on children. Lower = behind. Matches Godot `z_index`, Unity `sortingOrder`, CSS `z-index`. |
+| `zOrder` | number | Back-to-front paint order on children. Lower = behind. Maps to `CanvasItem.z_index`. |
 | `parentSliceIndex` | number | Set on each child, points at the composite parent. Used to group children. |
 
 The table above lists every field this skill reads; treat any other field in the pack manifest as opaque.
@@ -201,7 +201,7 @@ For the full instantiation flow (op JSON, examples), use `instantiate-asset-pack
 
 ### Legacy compatibility
 
-Older packs (saved before the rename) used different field names. Always fall back:
+Older packs use different field names. Always fall back:
 
 ```
 const zOrder      = slice.zOrder      ?? slice.layerIndex   ?? packFileIndex;

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

@@ -36,14 +36,12 @@ If `CLAUDE.md` says "skip the brainstorm, just build it" and a skill says "alway
 Two layers:
 
 - **Skills** — discipline guides that fire on specific situations: brainstorming a game, designing a mechanic, building an FPS controller, debugging a crash, shipping a build. Each one is a SKILL.md you load via the Skill tool.
-- **MCP tools** — `summer_*` tools that talk to the running Summer Engine on `localhost:6550`. Scene mutation (`summer_add_node`, `summer_set_prop`), inspection (`summer_get_scene_tree`, `summer_inspect_node`), play/diagnostics (`summer_play`, `summer_get_diagnostics`), asset import/generation (`summer_import_from_url`, `summer_generate_3d`), and 30+ more.
+- **MCP tools** — `summer_*` tools that talk to the running Summer Engine on `localhost:6550`. Scene mutation (`summer_add_node`, `summer_set_prop`), inspection (`summer_get_scene_tree`, `summer_inspect_node`), play/diagnostics (`summer_play`, `summer_get_diagnostics`), asset import/generation (`summer_import_from_url`, `summer_generate_3d`), and the rest of the `summer_*` set.
 
 **Scripting language:** The user is making a Summer game with the Summer SDK.
-GDScript is the default creator language. Summer currently uses the 4.6.1
-upstream technical base, plans to adopt 4.7.1 next, and follows upstream
-continuously. Confirm version-sensitive behavior from the engine's own version
-string rather than turning that base into the product identity. You can write
-game code in either:
+GDScript is the default creator language. Summer Engine follows its upstream
+technical base continuously, so confirm version-sensitive behavior from the
+engine's own version string. You can write game code in either:
 
 - **GDScript** (`.gd`) — the default. Best supported by Summer skills (see `gdscript-patterns`). Use this unless the user has explicitly chosen C#.
 - **C#** (`.cs`) — supported by the shipped Mono build. The GDScript
@@ -150,7 +148,7 @@ Run `summer doctor` early in a fresh Summer session when setup, MCP tools, slash
 npx clear-npx-cache && npx -y summer-engine@latest setup <agent> --yes --force
 ```
 
-Use the dist-tag `summer doctor` recommends: `@latest` normally, `@next` (with `--channel next`) when this CLI was installed from the soaking release, otherwise the MCP server silently drops back to the older `latest`. Use the real agent slug from doctor or the current environment (`claude-code`, `codex`, `cursor`, `gemini`, `github-copilot`, `vscode-copilot`, `opencode`, etc.).
+Use the dist-tag `summer doctor` recommends: `@latest` normally, `@next` (with `--channel next`) when this CLI was installed from the soaking release, otherwise the MCP server silently drops back to the older `latest`. Use the real agent slug from doctor or the current environment (`claude-code`, `codex`, `cursor`, `antigravity`, `github-copilot`, `vscode-copilot`, `opencode`, etc.).
 
 Why this exact command matters:
 

package/library/skills/vehicle-model/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: vehicle-model
-description: "Generate a hard-surface vehicle — car, spaceship, mech, boat, tank — static mesh with optional detail-texture pass, wired as Vehicle3D or MeshInstance3D."
+description: "Generate a hard-surface vehicle — car, spaceship, mech, boat, tank — static mesh with optional detail-texture pass, wired as VehicleBody3D or MeshInstance3D."
 license: MIT
 compatibility: [Cursor, Claude Code, Windsurf, Codex]
 category: 3d-assets
@@ -101,7 +101,7 @@ Nothing in the prompt text "triggers" multi-view. The phrase `front and 3/4 side
 
 ### 4. Confirm and call
 
-> About to generate `red_race_car` via `hunyuan`, target ~25k tris, multi-angle ref. ~$0.60, ~90s. OK?
+> About to generate `red_race_car` via `hunyuan`, target ~25k tris, multi-angle ref. Uses credits, ~90s. OK?
 
 ```
 summer_generate_3d(
@@ -145,7 +145,7 @@ This re-textures the existing mesh with sharper detail — panel lines, decals,
 | Use case | Parent type | Notes |
 |---|---|---|
 | Player-driven (car, bike, hover) | `VehicleBody3D` (wheeled) or `RigidBody3D` (free physics) | Add `VehicleWheel3D` children for wheeled vehicles |
-| Player-driven (spaceship, mech) | `RigidBody3D` or `CharacterBody3D` | Custom thrust / walk code, see `fps-controller` |
+| Player-driven (spaceship, mech) | `RigidBody3D` or `CharacterBody3D` | Custom thrust / walk code (`character-movement` for walkers) |
 | Background scenery (parked, flyby) | `MeshInstance3D` under a `Node3D` | No physics, no collision needed for distant traffic |
 | Background traffic (moving but not interactive) | `Node3D` + `AnimationPlayer` driving the position | Cheap, no physics overhead |
 
@@ -161,7 +161,7 @@ summer_set_resource_property(scenePath="res://main.tscn", nodePath="./World/Race
 summer_save_scene(scenePath="res://main.tscn")
 ```
 
-A `.glb` cannot be assigned to `MeshInstance3D.mesh` — an imported `.glb` is a scene, not a `Mesh` (`ResourceLoader.get_recognized_extensions_for_type("Mesh")` on the shipped 4.6.1 binary returns `["tres", "mesh", "res"]`, no `glb`). Instantiate it. Assigning a bare class name like `"BoxShape3D"` to a resource property auto-instantiates it, which is how you get a shape you can then size.
+A `.glb` cannot be assigned to `MeshInstance3D.mesh` — an imported `.glb` is a scene, not a `Mesh` (`ResourceLoader.get_recognized_extensions_for_type("Mesh")` on the shipped engine returns `["tres", "mesh", "res"]`, no `glb`). Instantiate it. Assigning a bare class name like `"BoxShape3D"` to a resource property auto-instantiates it, which is how you get a shape you can then size.
 
 Every scene-mutating tool takes an explicit `scenePath`; node paths are relative to that scene's root (`./`); `summer_set_prop`'s property argument is `key`; and `summer_set_resource_property` needs all five of `scenePath`, `nodePath`, `resourceProperty`, `subProperty`, `value`.
 
@@ -185,7 +185,7 @@ summer_save_scene(scenePath="res://main.tscn")
 ## Edge cases
 
 - **Tracked vehicle (tank).** AI mesh-gen handles the hull but the tracks come back as a fused ring. Generate the hull only, then add tracks as a separate `prop-model` (or use a tiled texture on a torus). For animation, scroll the track texture's UV.
-- **Articulated vehicle (mech with shoulders, hips, knees).** The mesh is one piece — joints aren't separated. For animated mechs, treat as a humanoid: generate as `character-model` with the rig pass, then animate via `generate-motion` (custom backend, prompt as "mech walks heavily").
+- **Articulated vehicle (mech with shoulders, hips, knees).** The mesh is one piece — joints aren't separated. For animated mechs, treat as a humanoid: generate as `character-model` with the rig pass, then animate with `text-to-motion` (prompt "walks heavily").
 - **Vehicle with rotor (helicopter, drone).** Generate without rotor, then add the rotor as a separate `prop-model` and parent it. Spin via code in `_process`.
 - **Open-top vehicle (convertible, jeep).** Specify "open top, no roof" — defaults often add a roof.
 - **The user wants the cockpit interior visible.** Generate exterior here, then a separate `prop-model` for the interior, and switch meshes when the camera enters first-person view.
@@ -202,7 +202,7 @@ summer_save_scene(scenePath="res://main.tscn")
 After the vehicle is wired:
 
 > `race_car.glb` placed at `./World/RaceCar` as a VehicleBody3D. Next:
-> - **Vehicle controls:** WASD steering / accel — see `fps-controller` for the vehicle controller pattern (or write directly with `engine_force`, `steering`, and `brake` on VehicleBody3D).
+> - **Vehicle controls:** WASD steering / accel — write them with `engine_force`, `steering`, and `brake` on VehicleBody3D.
 > - **Driver character:** generate via `character-model` and parent to the seat position.
 > - **Engine sound + tire screech:** `sound-effect` for one-shots, `ambient-bed` for the engine loop.
 > - **Particles:** exhaust smoke, dust trail, sparks on collision — `vfx-smoke` / `vfx-hit-spark` or built-in GPUParticles3D.
@@ -212,5 +212,4 @@ After the vehicle is wired:
 - `character-model` — for the driver/pilot.
 - `prop-model` — for separable parts (rotors, decals as decals, modular kit pieces).
 - `asset-strategy` — meta-router.
-- `fps-controller` — for player-driven vehicle input wiring.
 - `../../references/mcp-tools-reference/mcp-tools-reference.md` — `summer_generate_3d` schema, including `kind: "texture"` for the secondary detail pass.

package/library/skills/vehicle-model/resource.yaml

@@ -1,10 +1,10 @@
 id: skill/vehicle-model
 kind: skill
 version: 1.0.3
-summary: Generate a hard-surface vehicle — car, spaceship, mech, boat, tank — static mesh with optional detail-texture pass, wired as Vehicle3D or MeshInstance3D.
+summary: Generate a hard-surface vehicle — car, spaceship, mech, boat, tank — static mesh with optional detail-texture pass, wired as VehicleBody3D or MeshInstance3D.
 use_when:
   - generating a hard-surface vehicle — car, motorcycle, spaceship, hover bike, boat, mech, tank, helicopter
-  - a racing, flying, or combat game needs a hard-surface vehicle mesh as a Vehicle3D or MeshInstance3D
+  - a racing, flying, or combat game needs a hard-surface vehicle mesh as a VehicleBody3D or MeshInstance3D
 facets:
   lifecycle:
     - build

package/library/skills/verification-before-completion/SKILL.md

@@ -109,12 +109,11 @@ Bad: Trust agent report
 
 ## Why This Matters
 
-From 24 failure memories:
-- the user said "I don't believe you" - trust broken
-- Undefined functions shipped - would crash
-- Missing requirements shipped - incomplete features
-- Time wasted on false completion → redirect → rework
-- Violates: "Honesty is a core value. If you lie, you'll be replaced."
+False completion claims cost trust and time:
+- The user stops believing your reports.
+- Undefined functions ship and crash.
+- Missing requirements ship as incomplete features.
+- Time goes to redirecting and rework.
 
 ## When To Apply
 

package/library/skills/vfx-dissolve/SKILL.md

@@ -25,8 +25,8 @@ The dissolve shader samples 3D noise per fragment and clips pixels whose noise v
 
 ## When NOT to use
 
-- The user wants *fire* on the object that doesn't consume it — use `fire`, not dissolve. Dissolve makes the mesh disappear; fire just sits on top.
-- The user wants a particle-driven ash cloud as the object disappears — pair this with `smoke` (recolor to ash gray) spawned at the dissolving mesh's bounds.
+- The user wants *fire* on the object that doesn't consume it — use `vfx-fire`, not dissolve. Dissolve makes the mesh disappear; fire just sits on top.
+- The user wants a particle-driven ash cloud as the object disappears — pair this with `vfx-smoke` (recolor to ash gray) spawned at the dissolving mesh's bounds.
 - The user wants a fade-out via alpha (cheap, no shader) — set `transparency = TRANSPARENCY_ALPHA` and tween `albedo_color.a` to 0. Dissolve is better but more expensive.
 - The user wants the *world* to dissolve in for a level transition — that's a screen-space post-process, not this per-mesh recipe.
 - The character has skinned mesh + multiple materials — this works but you have to override every material slot. Confirm with user; consider a fade-out instead.
@@ -307,7 +307,7 @@ noise_scale    = 3.0
 
 ### thanos-snap
 
-Fast, fine grain, blue edge for the cosmic feel. Pair with `smoke` in pale gray for ash particles rising.
+Fast, fine grain, blue edge for the cosmic feel. Pair with `vfx-smoke` in pale gray for ash particles rising.
 
 ```
 duration       = 0.8
@@ -319,7 +319,7 @@ noise_scale    = 8.0
 
 ### holy-banish
 
-Slow, white edge, big halo. Add `magic-glow` underneath for a beam of light.
+Slow, white edge, big halo. Add `vfx-magic-glow` underneath for a beam of light.
 
 ```
 duration       = 2.5

package/library/skills/vfx-fire/SKILL.md

@@ -19,14 +19,14 @@ Fire in games is almost never a video clip and never an AI-generated sprite. It'
 - "Make a campfire / bonfire / hearth flame."
 - "Light the brazier."
 - "I need a candle flame on this candlestick."
-- "The dragon needs a flame breath" (use this for the persistent emitter; pair with a one-shot `muzzle-flash` for the burst).
+- "The dragon needs a flame breath" (use this for the persistent emitter; pair with a one-shot `vfx-muzzle-flash` for the burst).
 - The player set something on fire and you need a continuous, physically-anchored flame.
 
 ## When NOT to use
 
-- The user wants an object to *burn away* (mesh disintegrating with a fire edge) — route to `dissolve`. Fire is a separate effect; pair them.
-- The user wants smoke without flame — go straight to `smoke`. (Most fires want a smoke trail above; spawn this recipe and add `smoke` on top.)
-- The user wants a one-frame muzzle flash from a gun — that's `muzzle-flash`, not fire.
+- The user wants an object to *burn away* (mesh disintegrating with a fire edge) — route to `vfx-dissolve`. Fire is a separate effect; pair them.
+- The user wants smoke without flame — go straight to `vfx-smoke`. (Most fires want a smoke trail above; spawn this recipe and add `vfx-smoke` on top.)
+- The user wants a one-frame muzzle flash from a gun — that's `vfx-muzzle-flash`, not fire.
 - The user wants 2D fire on a UI element — use `canvas_item` shader; this recipe is `spatial`/`particles`.
 - The user wants stylized magic flame (blue, purple, ethereal) — use this recipe and load the `magic-fire` variant in the cookbook below.
 
@@ -397,7 +397,7 @@ OmniLight3D: light_energy = 1.6, omni_range = 6.0
 
 ### bonfire
 
-Wide, tall, hungry. Pair with `smoke` directly above.
+Wide, tall, hungry. Pair with `vfx-smoke` directly above.
 
 ```
 particle_count = 256
@@ -442,7 +442,7 @@ OmniLight3D: light_color = Color(0.40, 0.65, 1.0), light_energy = 2.4
 ## Anti-patterns
 
 - **Spatial-only shader on the visual quad.** It still works, but you forgot `blend_add` + `unshaded` and the flame looks like a flat orange triangle in shadow. Always: `render_mode unshaded, blend_add, depth_draw_never;`.
-- **Looping a one-shot emitter.** `one_shot = false` for fire (continuous). One-shot is for `muzzle-flash` and `hit-spark`.
+- **Looping a one-shot emitter.** `one_shot = false` for fire (continuous). One-shot is for `vfx-muzzle-flash` and `vfx-hit-spark`.
 - **Missing `cull_disabled`.** Particles billboard toward camera; if you cull backfaces, the flame disappears at certain angles.
 - **`depth_draw_opaque` on the visual material.** You'll z-fight with anything inside the flame (the torch handle). Use `depth_draw_never`.
 - **OmniLight3D parented under the GPUParticles3D.** The particles emit in local space; the light moves with them. Sibling, not child.

package/library/skills/vfx-fire/_building-blocks/additive-billboard-particles.md

@@ -1,6 +1,6 @@
 # Additive Billboard Particles — Canonical Material Settings
 
-Reusable material configuration for additive particle billboards (motes, sparks, glow, ash). Used by `magic-glow`, optionally substitutable in `hit-spark` and `fire` if a custom shader is overkill.
+Reusable material configuration for additive particle billboards (motes, sparks, glow, ash). Used by `vfx-magic-glow`, optionally substitutable in `vfx-hit-spark` and `vfx-fire` if a custom shader is overkill.
 
 `BaseMaterial3D` is abstract — `BaseMaterial3D.new()` is a parse error ("Native class
 "BaseMaterial3D" cannot be constructed as it is abstract"). Instantiate
@@ -27,8 +27,8 @@ bm.emission = Color(R, G, B)          # usually same as albedo for single-color
 
 ## When to use this vs a custom shader
 
-- **Use this `StandardMaterial3D` config** when the effect is just a tinted soft-circle mote (magic glow, sparkles, dust). Less code, faster iteration, free Godot-managed billboard math.
-- **Per-particle color over age does NOT need a custom shader.** `ParticleProcessMaterial` has `color_ramp`, `color_initial_ramp`, `alpha_curve` and `emission_curve` (all verified present in 4.6) — those drive the particle's `COLOR` from age and feed straight into a plain `StandardMaterial3D`. Reach for a ramp before reaching for a shader.
+- **Use this `StandardMaterial3D` config** when the effect is just a tinted soft-circle mote (magic glow, sparkles, dust). Less code, faster iteration, free engine-managed billboard math.
+- **Per-particle color over age does NOT need a custom shader.** `ParticleProcessMaterial` has `color_ramp`, `color_initial_ramp`, `alpha_curve` and `emission_curve` (all present on the shipped engine) — those drive the particle's `COLOR` from age and feed straight into a plain `StandardMaterial3D`. Reach for a ramp before reaching for a shader.
 - **Use a custom `ShaderMaterial`** when you need per-fragment shape masks (muzzle flash star burst), noise-distorted UVs (fire, smoke), or anything that varies *within* the quad. Those are what `StandardMaterial3D` genuinely can't express.
 - If a custom shader does need the particle age, note that the age lives in `INSTANCE_CUSTOM.y` (normalized by `INSTANCE_CUSTOM.w`, the lifetime), that `INSTANCE_CUSTOM.x` is the rotation angle — not the age — and that `INSTANCE_CUSTOM` is **vertex-stage only**. Pass it to `fragment()` through a `varying`.
 

package/library/skills/vfx-hit-spark/SKILL.md

@@ -21,14 +21,14 @@ Tiny stretched additive billboards spraying outward from an impact point, orient
 - "Footstep sparks on stone for the heavy armor."
 - "Ricochet sparks when the projectile glances off."
 - "Mining: sparks fly when pickaxe hits rock."
-- Endpoint sparks on `lightning` and `muzzle-flash` recipes (they reference this).
+- Endpoint sparks on `vfx-lightning` and `vfx-muzzle-flash` recipes (they reference this).
 
 ## When NOT to use
 
-- The user wants a *flash* at the impact, not a spray of particles — use `muzzle-flash` (recolor it).
+- The user wants a *flash* at the impact, not a spray of particles — use `vfx-muzzle-flash` (recolor it).
 - The user wants debris chunks (rock pieces, splinters) — those are physics objects, not particles. Spawn `RigidBody3D` shards, then sparks on top.
-- The user wants water droplets at a water impact — recolor this recipe blue/white (it works) or pair with `water-ripple` for the ring on the surface.
-- The user wants persistent burning sparks that linger and cool down — that's a hybrid; use this for the burst, then tiny `fire` particles for residual embers.
+- The user wants water droplets at a water impact — recolor this recipe blue/white (it works) or pair with `vfx-water-ripple` for the ring on the surface.
+- The user wants persistent burning sparks that linger and cool down — that's a hybrid; use this for the burst, then tiny `vfx-fire` particles for residual embers.
 
 ## Recipe
 

package/library/skills/vfx-hit-spark/_building-blocks/additive-billboard-particles.md

@@ -1,6 +1,6 @@
 # Additive Billboard Particles — Canonical Material Settings
 
-Reusable material configuration for additive particle billboards (motes, sparks, glow, ash). Used by `magic-glow`, optionally substitutable in `hit-spark` and `fire` if a custom shader is overkill.
+Reusable material configuration for additive particle billboards (motes, sparks, glow, ash). Used by `vfx-magic-glow`, optionally substitutable in `vfx-hit-spark` and `vfx-fire` if a custom shader is overkill.
 
 `BaseMaterial3D` is abstract — `BaseMaterial3D.new()` is a parse error ("Native class
 "BaseMaterial3D" cannot be constructed as it is abstract"). Instantiate
@@ -27,8 +27,8 @@ bm.emission = Color(R, G, B)          # usually same as albedo for single-color
 
 ## When to use this vs a custom shader
 
-- **Use this `StandardMaterial3D` config** when the effect is just a tinted soft-circle mote (magic glow, sparkles, dust). Less code, faster iteration, free Godot-managed billboard math.
-- **Per-particle color over age does NOT need a custom shader.** `ParticleProcessMaterial` has `color_ramp`, `color_initial_ramp`, `alpha_curve` and `emission_curve` (all verified present in 4.6) — those drive the particle's `COLOR` from age and feed straight into a plain `StandardMaterial3D`. Reach for a ramp before reaching for a shader.
+- **Use this `StandardMaterial3D` config** when the effect is just a tinted soft-circle mote (magic glow, sparkles, dust). Less code, faster iteration, free engine-managed billboard math.
+- **Per-particle color over age does NOT need a custom shader.** `ParticleProcessMaterial` has `color_ramp`, `color_initial_ramp`, `alpha_curve` and `emission_curve` (all present on the shipped engine) — those drive the particle's `COLOR` from age and feed straight into a plain `StandardMaterial3D`. Reach for a ramp before reaching for a shader.
 - **Use a custom `ShaderMaterial`** when you need per-fragment shape masks (muzzle flash star burst), noise-distorted UVs (fire, smoke), or anything that varies *within* the quad. Those are what `StandardMaterial3D` genuinely can't express.
 - If a custom shader does need the particle age, note that the age lives in `INSTANCE_CUSTOM.y` (normalized by `INSTANCE_CUSTOM.w`, the lifetime), that `INSTANCE_CUSTOM.x` is the rotation angle — not the age — and that `INSTANCE_CUSTOM` is **vertex-stage only**. Pass it to `fragment()` through a `varying`.
 

package/library/skills/vfx-lightning/SKILL.md

@@ -11,20 +11,20 @@ paths: ["**/*.tscn", "**/*.gd", "**/*.gdshader", "addons/vfx/**"]
 
 # lightning — Procedural Jagged Bolt
 
-A lightning bolt is a noisy line from A to B, drawn for ~150 ms with a glow shader, sparks at both endpoints, and camera shake on cast. The recipe builds the jagged path in GDScript (midpoint displacement on a polyline), feeds the verts into an `ImmediateMesh`, applies a `ShaderMaterial` for additive bloom + flicker, spawns `hit-spark` particles at each endpoint, and calls `CameraShake.add_trauma(0.6)` for the impact. Used for shock spells, tesla coils, weapon discharges, electric enemies.
+A lightning bolt is a noisy line from A to B, drawn for ~150 ms with a glow shader, sparks at both endpoints, and camera shake on cast. The recipe builds the jagged path in GDScript (midpoint displacement on a polyline), feeds the verts into an `ImmediateMesh`, applies a `ShaderMaterial` for additive bloom + flicker, spawns `vfx-hit-spark` particles at each endpoint, and calls `CameraShake.add_trauma(0.6)` for the impact. Used for shock spells, tesla coils, weapon discharges, electric enemies.
 
 ## When to use
 
 - "Cast a lightning bolt from the wizard's hand to the enemy."
 - "Chain lightning from one enemy to the next." (call `cast_lightning` per segment)
 - "Tesla coil firing at the player every 2 seconds."
-- "Energy weapon laser." (use the `laser-beam` variant)
+- "Energy weapon laser." (use the `plasma-laser` variant)
 - "Lightning strike from the sky."
 - The user wants a *short, dramatic* energy connection between two points.
 
 ## When NOT to use
 
-- The user wants a continuous beam that holds (e.g., laser sniper holding the trigger) — use the same shader on a `MeshInstance3D` cylinder with continuous emission, not the `ImmediateMesh` one-shot pattern. (See variants for `held-beam`.)
+- The user wants a continuous beam that holds (e.g., laser sniper holding the trigger) — use the same shader on a `MeshInstance3D` cylinder with continuous emission, not the `ImmediateMesh` one-shot pattern. (See the `plasma-laser` variant.)
 - The user wants ambient electricity *on* an object (Frankenstein arcs) — use a custom shader on the mesh with screen-space arcs; this recipe is for two-point bolts.
 - The user wants a 2D lightning effect on UI — `canvas_item` shader, not this.
 - The user wants a tracer line for a bullet — use a simple `ImmediateMesh`
@@ -369,7 +369,7 @@ trauma_amount = 0.0  # no shake on a held beam
 
 - One bolt at `SEGMENTS = 18`: 19 path points × 2 verts = 38 verts for the trunk, plus 2 × (`SEGMENTS / 3` + 1) = 14 verts per forked branch. One draw call, freed after 150 ms. Effectively free.
 - Chain lightning with 5 segments stays in the same negligible band — that is an order-of-magnitude expectation, not a measurement.
-- Endpoint sparks (instantiated `hit-spark` scenes) are the bigger cost — 64 particles × 2 = 128 particles per cast. Throttle for storms (see edge cases).
+- Endpoint sparks (instantiated `vfx-hit-spark` scenes) are the bigger cost — 64 particles × 2 = 128 particles per cast. Throttle for storms (see edge cases).
 - The shader's flicker uses `floor(TIME * flicker_rate)`, so it ages with `TIME` not particle time — flicker is consistent across all bolts in flight.
 
 ## Edge cases
@@ -378,7 +378,7 @@ trauma_amount = 0.0  # no shake on a held beam
 - **Bolt passes through a wall.** Visual only — the bolt shader doesn't depth test. If the user wants the bolt to be occluded by walls, set `depth_draw_opaque` and let the depth buffer cull it (loses the additive bloom in front of geometry).
 - **Bolt origin and target at the same point.** Falloff goes to zero; `_generate_path` returns a degenerate strip. Add a guard: if `(to - from).length() < 0.01`, skip.
 - **Underwater bolt.** Tint blue-green, drop `emission_boost` to 5.0; underwater bloom is muted.
-- **First-person caster (player's hand).** The bolt starts inside the player's view and reads as a flash. Use a `held-beam` variant or shorten `LIFETIME` to 0.08.
+- **First-person caster (player's hand).** The bolt starts inside the player's view and reads as a flash. Use the `plasma-laser` variant or shorten `LIFETIME` to 0.08.
 - **No `CameraShake` autoload registered.** `get_node_or_null("/root/CameraShake")` returns null and the `if cs` check skips the call; the bolt fires without shake. Suggest `_building-blocks/trauma-shake-snippet.md` to wire it.
 
 ## Fallback (no MCP)

package/library/skills/vfx-lightning/_building-blocks/additive-billboard-particles.md

@@ -1,6 +1,6 @@
 # Additive Billboard Particles — Canonical Material Settings
 
-Reusable material configuration for additive particle billboards (motes, sparks, glow, ash). Used by `magic-glow`, optionally substitutable in `hit-spark` and `fire` if a custom shader is overkill.
+Reusable material configuration for additive particle billboards (motes, sparks, glow, ash). Used by `vfx-magic-glow`, optionally substitutable in `vfx-hit-spark` and `vfx-fire` if a custom shader is overkill.
 
 `BaseMaterial3D` is abstract — `BaseMaterial3D.new()` is a parse error ("Native class
 "BaseMaterial3D" cannot be constructed as it is abstract"). Instantiate
@@ -27,8 +27,8 @@ bm.emission = Color(R, G, B)          # usually same as albedo for single-color
 
 ## When to use this vs a custom shader
 
-- **Use this `StandardMaterial3D` config** when the effect is just a tinted soft-circle mote (magic glow, sparkles, dust). Less code, faster iteration, free Godot-managed billboard math.
-- **Per-particle color over age does NOT need a custom shader.** `ParticleProcessMaterial` has `color_ramp`, `color_initial_ramp`, `alpha_curve` and `emission_curve` (all verified present in 4.6) — those drive the particle's `COLOR` from age and feed straight into a plain `StandardMaterial3D`. Reach for a ramp before reaching for a shader.
+- **Use this `StandardMaterial3D` config** when the effect is just a tinted soft-circle mote (magic glow, sparkles, dust). Less code, faster iteration, free engine-managed billboard math.
+- **Per-particle color over age does NOT need a custom shader.** `ParticleProcessMaterial` has `color_ramp`, `color_initial_ramp`, `alpha_curve` and `emission_curve` (all present on the shipped engine) — those drive the particle's `COLOR` from age and feed straight into a plain `StandardMaterial3D`. Reach for a ramp before reaching for a shader.
 - **Use a custom `ShaderMaterial`** when you need per-fragment shape masks (muzzle flash star burst), noise-distorted UVs (fire, smoke), or anything that varies *within* the quad. Those are what `StandardMaterial3D` genuinely can't express.
 - If a custom shader does need the particle age, note that the age lives in `INSTANCE_CUSTOM.y` (normalized by `INSTANCE_CUSTOM.w`, the lifetime), that `INSTANCE_CUSTOM.x` is the rotation angle — not the age — and that `INSTANCE_CUSTOM` is **vertex-stage only**. Pass it to `fragment()` through a `varying`.
 

package/library/skills/vfx-lightning/_building-blocks/trauma-shake-snippet.md

@@ -1,6 +1,6 @@
 # Trauma Camera Shake — Reusable Snippet
 
-Variant of the canonical "trauma model" shake (see `visual-effects/game-feel/SKILL.md` for the full game-feel discipline). Lightning and explosion recipes call `add_trauma()` to chain visual impact with screen-level reaction.
+Variant of the canonical "trauma model" shake (the `game-feel` skill has the full game-feel discipline). Lightning and explosion recipes call `add_trauma()` to chain visual impact with screen-level reaction.
 
 ## Setup (autoload script)
 
@@ -15,18 +15,24 @@ var max_offset: Vector3 = Vector3(0.4, 0.4, 0.0)
 var max_yaw: float = 0.05
 var max_pitch: float = 0.05
 var camera: Camera3D
+var _rot_offset := Vector2.ZERO  # shake rotation applied last frame
 
 func _process(delta: float) -> void:
     if camera == null:
         camera = get_viewport().get_camera_3d()
         if camera == null:
             return
+    # Undo last frame's shake first, so the camera never drifts.
+    camera.rotation.x -= _rot_offset.x
+    camera.rotation.y -= _rot_offset.y
+    _rot_offset = Vector2.ZERO
     if trauma > 0.0:
         var s := trauma * trauma  # perceived intensity grows quadratically
         camera.h_offset = max_offset.x * s * (randf() * 2.0 - 1.0)
         camera.v_offset = max_offset.y * s * (randf() * 2.0 - 1.0)
-        camera.rotation.x += max_pitch * s * (randf() * 2.0 - 1.0) * 0.1
-        camera.rotation.y += max_yaw * s * (randf() * 2.0 - 1.0) * 0.1
+        _rot_offset = Vector2(max_pitch * s * (randf() * 2.0 - 1.0), max_yaw * s * (randf() * 2.0 - 1.0))
+        camera.rotation.x += _rot_offset.x
+        camera.rotation.y += _rot_offset.y
         trauma = max(0.0, trauma - trauma_decay * delta)
     else:
         camera.h_offset = 0.0

package/library/skills/vfx-magic-glow/SKILL.md

@@ -21,13 +21,13 @@ Three layered cues that together read as "magical": a pulsing `OmniLight3D` (sin
 - "Wisp / fairy / firefly companion."
 - "The summoning circle is active."
 - "Quest item glows so the player notices it."
-- Pre-charge phase before casting `lightning` or `muzzle-flash` (charge-up beam).
+- Pre-charge phase before casting `vfx-lightning` or `vfx-muzzle-flash` (charge-up beam).
 
 ## When NOT to use
 
 - The user wants a static, non-animated glow — just enable emission on the mesh's material; this recipe is overkill.
-- The user wants flames, not a glow — use `fire` (or `magic-fire` variant of `fire`).
-- The user wants a beam shooting out, not an aura — use `lightning` with the `plasma-laser` variant.
+- The user wants flames, not a glow — use `vfx-fire` (or `magic-fire` variant of `vfx-fire`).
+- The user wants a beam shooting out, not an aura — use `vfx-lightning` with the `plasma-laser` variant.
 - The user wants a screen-space bloom on the whole scene — that's `WorldEnvironment.glow_*`, not a per-object recipe.
 - The user wants a 2D glow on a UI sprite — use `canvas_item` shader with a radial gradient, not this 3D recipe.
 
@@ -415,7 +415,7 @@ manually in Summer Engine:
 
 After firing this recipe, suggest:
 
-- `vfx-lightning` — perfect pre-cast charge-up. Use the `charge-up` variant and ramp `set_intensity(0→1)` then call `Lightning.cast_lightning`.
+- `vfx-lightning` — pre-cast charge-up. Use this skill's `charge-up` variant, ramp `set_intensity(0→1)` then call `Lightning.cast_lightning`.
 - `vfx-dissolve` — pair `summon-arrival` (materialize_object) with the `summoning-circle` variant.
 - `vfx-fire` (the `magic-fire` variant) — for items that should glow AND flame.
 - `game-feel` — slight time-dilation when picking up a pulsing quest item adds weight.

package/library/skills/vfx-magic-glow/_building-blocks/additive-billboard-particles.md

@@ -1,6 +1,6 @@
 # Additive Billboard Particles — Canonical Material Settings
 
-Reusable material configuration for additive particle billboards (motes, sparks, glow, ash). Used by `magic-glow`, optionally substitutable in `hit-spark` and `fire` if a custom shader is overkill.
+Reusable material configuration for additive particle billboards (motes, sparks, glow, ash). Used by `vfx-magic-glow`, optionally substitutable in `vfx-hit-spark` and `vfx-fire` if a custom shader is overkill.
 
 `BaseMaterial3D` is abstract — `BaseMaterial3D.new()` is a parse error ("Native class
 "BaseMaterial3D" cannot be constructed as it is abstract"). Instantiate
@@ -27,8 +27,8 @@ bm.emission = Color(R, G, B)          # usually same as albedo for single-color
 
 ## When to use this vs a custom shader
 
-- **Use this `StandardMaterial3D` config** when the effect is just a tinted soft-circle mote (magic glow, sparkles, dust). Less code, faster iteration, free Godot-managed billboard math.
-- **Per-particle color over age does NOT need a custom shader.** `ParticleProcessMaterial` has `color_ramp`, `color_initial_ramp`, `alpha_curve` and `emission_curve` (all verified present in 4.6) — those drive the particle's `COLOR` from age and feed straight into a plain `StandardMaterial3D`. Reach for a ramp before reaching for a shader.
+- **Use this `StandardMaterial3D` config** when the effect is just a tinted soft-circle mote (magic glow, sparkles, dust). Less code, faster iteration, free engine-managed billboard math.
+- **Per-particle color over age does NOT need a custom shader.** `ParticleProcessMaterial` has `color_ramp`, `color_initial_ramp`, `alpha_curve` and `emission_curve` (all present on the shipped engine) — those drive the particle's `COLOR` from age and feed straight into a plain `StandardMaterial3D`. Reach for a ramp before reaching for a shader.
 - **Use a custom `ShaderMaterial`** when you need per-fragment shape masks (muzzle flash star burst), noise-distorted UVs (fire, smoke), or anything that varies *within* the quad. Those are what `StandardMaterial3D` genuinely can't express.
 - If a custom shader does need the particle age, note that the age lives in `INSTANCE_CUSTOM.y` (normalized by `INSTANCE_CUSTOM.w`, the lifetime), that `INSTANCE_CUSTOM.x` is the rotation angle — not the age — and that `INSTANCE_CUSTOM` is **vertex-stage only**. Pass it to `fragment()` through a `varying`.
 

package/library/skills/vfx-muzzle-flash/SKILL.md

@@ -11,7 +11,7 @@ paths: ["**/*.tscn", "**/*.gd", "**/*.gdshader", "addons/vfx/**"]
 
 # muzzle-flash — One-Shot Star-Burst Flare
 
-A muzzle flash is on screen for 60–100 ms. Long enough to read, too short to animate. The recipe: a single billboarded quad with a star-burst gradient shader, fired by `restart()` on a weapon's `fired` signal, plus an `OmniLight3D` snapping on for 60 ms to light the room. Optional: a tiny GPUParticles3D one-shot for sparks. Doom Eternal does this. Half-Life 2 did this. Every shooter does this.
+A muzzle flash is on screen for 60–100 ms. Long enough to read, too short to animate. The recipe: a single billboarded quad with a star-burst gradient shader, fired by `restart()` on a weapon's `fired` signal, plus an `OmniLight3D` snapping on for 60 ms to light the room. Optional: a tiny GPUParticles3D one-shot for sparks. Most shooters use this pattern.
 
 ## When to use
 
@@ -23,12 +23,12 @@ A muzzle flash is on screen for 60–100 ms. Long enough to read, too short to a
 
 ## When NOT to use
 
-- The user wants a *continuous* flame (flamethrower) — use `fire`, not muzzle-flash.
-- The user wants the impact spark on the wall the bullet hit — that's `hit-spark`.
+- The user wants a *continuous* flame (flamethrower) — use `vfx-fire`, not muzzle-flash.
+- The user wants the impact spark on the wall the bullet hit — that's `vfx-hit-spark`.
 - The user wants a tracer line from barrel to target — use an `ImmediateMesh`
   recipe, not this. The current Summer build has no `Line3D`
   (`ClassDB.class_exists("Line3D")` is `false`).
-- The user wants a slow-glowing spell charge-up — use `magic-glow` for the buildup, then this for the release frame.
+- The user wants a slow-glowing spell charge-up — use `vfx-magic-glow` for the buildup, then this for the release frame.
 
 ## Recipe
 
@@ -377,7 +377,7 @@ After firing this recipe, suggest:
 
 - `vfx-hit-spark` — pair on the bullet impact end.
 - `vfx-smoke` — for a small puff at the barrel after the flash for high-caliber weapons.
-- `game-feel` — recoil camera kick + screen shake (`CameraShake.add_trauma(0.15)`) on every shot makes the flash feel 5× more powerful.
+- `game-feel` — recoil camera kick + screen shake (`CameraShake.add_trauma(0.15)`) on every shot makes the flash land much harder.
 - `sound-effect` — generate `9mm pistol shot, sharp crack, indoor, short tail, 400ms` and play in the same `fire()`.
 
 ## See also

package/library/skills/vfx-muzzle-flash/_building-blocks/additive-billboard-particles.md

@@ -1,6 +1,6 @@
 # Additive Billboard Particles — Canonical Material Settings
 
-Reusable material configuration for additive particle billboards (motes, sparks, glow, ash). Used by `magic-glow`, optionally substitutable in `hit-spark` and `fire` if a custom shader is overkill.
+Reusable material configuration for additive particle billboards (motes, sparks, glow, ash). Used by `vfx-magic-glow`, optionally substitutable in `vfx-hit-spark` and `vfx-fire` if a custom shader is overkill.
 
 `BaseMaterial3D` is abstract — `BaseMaterial3D.new()` is a parse error ("Native class
 "BaseMaterial3D" cannot be constructed as it is abstract"). Instantiate
@@ -27,8 +27,8 @@ bm.emission = Color(R, G, B)          # usually same as albedo for single-color
 
 ## When to use this vs a custom shader
 
-- **Use this `StandardMaterial3D` config** when the effect is just a tinted soft-circle mote (magic glow, sparkles, dust). Less code, faster iteration, free Godot-managed billboard math.
-- **Per-particle color over age does NOT need a custom shader.** `ParticleProcessMaterial` has `color_ramp`, `color_initial_ramp`, `alpha_curve` and `emission_curve` (all verified present in 4.6) — those drive the particle's `COLOR` from age and feed straight into a plain `StandardMaterial3D`. Reach for a ramp before reaching for a shader.
+- **Use this `StandardMaterial3D` config** when the effect is just a tinted soft-circle mote (magic glow, sparkles, dust). Less code, faster iteration, free engine-managed billboard math.
+- **Per-particle color over age does NOT need a custom shader.** `ParticleProcessMaterial` has `color_ramp`, `color_initial_ramp`, `alpha_curve` and `emission_curve` (all present on the shipped engine) — those drive the particle's `COLOR` from age and feed straight into a plain `StandardMaterial3D`. Reach for a ramp before reaching for a shader.
 - **Use a custom `ShaderMaterial`** when you need per-fragment shape masks (muzzle flash star burst), noise-distorted UVs (fire, smoke), or anything that varies *within* the quad. Those are what `StandardMaterial3D` genuinely can't express.
 - If a custom shader does need the particle age, note that the age lives in `INSTANCE_CUSTOM.y` (normalized by `INSTANCE_CUSTOM.w`, the lifetime), that `INSTANCE_CUSTOM.x` is the rotation angle — not the age — and that `INSTANCE_CUSTOM` is **vertex-stage only**. Pass it to `fragment()` through a `varying`.
 

package/library/skills/vfx-muzzle-flash/_building-blocks/trauma-shake-snippet.md

@@ -1,6 +1,6 @@
 # Trauma Camera Shake — Reusable Snippet
 
-Variant of the canonical "trauma model" shake (see `visual-effects/game-feel/SKILL.md` for the full game-feel discipline). Lightning and explosion recipes call `add_trauma()` to chain visual impact with screen-level reaction.
+Variant of the canonical "trauma model" shake (the `game-feel` skill has the full game-feel discipline). Lightning and explosion recipes call `add_trauma()` to chain visual impact with screen-level reaction.
 
 ## Setup (autoload script)
 
@@ -15,18 +15,24 @@ var max_offset: Vector3 = Vector3(0.4, 0.4, 0.0)
 var max_yaw: float = 0.05
 var max_pitch: float = 0.05
 var camera: Camera3D
+var _rot_offset := Vector2.ZERO  # shake rotation applied last frame
 
 func _process(delta: float) -> void:
     if camera == null:
         camera = get_viewport().get_camera_3d()
         if camera == null:
             return
+    # Undo last frame's shake first, so the camera never drifts.
+    camera.rotation.x -= _rot_offset.x
+    camera.rotation.y -= _rot_offset.y
+    _rot_offset = Vector2.ZERO
     if trauma > 0.0:
         var s := trauma * trauma  # perceived intensity grows quadratically
         camera.h_offset = max_offset.x * s * (randf() * 2.0 - 1.0)
         camera.v_offset = max_offset.y * s * (randf() * 2.0 - 1.0)
-        camera.rotation.x += max_pitch * s * (randf() * 2.0 - 1.0) * 0.1
-        camera.rotation.y += max_yaw * s * (randf() * 2.0 - 1.0) * 0.1
+        _rot_offset = Vector2(max_pitch * s * (randf() * 2.0 - 1.0), max_yaw * s * (randf() * 2.0 - 1.0))
+        camera.rotation.x += _rot_offset.x
+        camera.rotation.y += _rot_offset.y
         trauma = max(0.0, trauma - trauma_decay * delta)
     else:
         camera.h_offset = 0.0

package/library/skills/vfx-smoke/SKILL.md

@@ -11,7 +11,7 @@ paths: ["**/*.tscn", "**/*.gd", "**/*.gdshader", "addons/vfx/**"]
 
 # smoke — Soft Particle Smoke Plume
 
-Smoke is the same particle pattern as fire — billboard quads emitted from a small disc, drifting upward — except the shader is dim, soft, low-emission, and tinted by depth instead of glowing. Slower spawn rate, longer lifetime, larger end scale. Pair it with `fire` for any campfire/torch/explosion. Used everywhere: chimney smoke, smoldering wreckage, smoke trails behind rockets, steam from vents, fog clouds.
+Smoke is the same particle pattern as fire — billboard quads emitted from a small disc, drifting upward — except the shader is dim, soft, low-emission, and tinted by depth instead of glowing. Slower spawn rate, longer lifetime, larger end scale. Pair it with `vfx-fire` for any campfire/torch/explosion. Used everywhere: chimney smoke, smoldering wreckage, smoke trails behind rockets, steam from vents, fog clouds.
 
 ## When to use
 
@@ -21,12 +21,12 @@ Smoke is the same particle pattern as fire — billboard quads emitted from a sm
 - "Steam from the vent."
 - "Smoke from the smoldering wreckage."
 - "Fog cloud at the cave entrance."
-- After spawning `fire`, smoke almost always belongs above it.
+- After spawning `vfx-fire`, smoke almost always belongs above it.
 
 ## When NOT to use
 
-- The user wants flames, not smoke — use `fire`.
-- The user wants a giant ground-hugging fog volume — use a `FogVolume` node with the `WorldEnvironment.volumetric_fog` shader, not a particle system. Particles don't scale to room-size fog.
+- The user wants flames, not smoke — use `vfx-fire`.
+- The user wants a giant ground-hugging fog volume — use a `FogVolume` node with volumetric fog enabled in the `WorldEnvironment`, not a particle system. Particles don't scale to room-size fog.
 - The user wants a 2D smoke effect — `canvas_item` shader, not this.
 - The user wants the smoke to physically interact with the player (pushed by movement) — particles are visual; use a `FogVolume` + script that follows the player.
 - The user wants thick black bonfire smoke that completely occludes — bump density way up, but consider a `FogVolume` for genuine visual occlusion.
@@ -334,7 +334,7 @@ color_old      = Color(0.55, 0.55, 0.55)
 
 ### black-fire-smoke
 
-Burning oil / tires. Pair with `fire` set to `bonfire`.
+Burning oil / tires. Pair with `vfx-fire` set to `bonfire`.
 
 ```
 particle_count = 96

package/library/skills/vfx-water-ripple/SKILL.md

@@ -24,9 +24,9 @@ Concentric expanding rings on a water surface, normal-distorted so the ripple ac
 
 ## When NOT to use
 
-- The user wants the *whole* water surface to wave (Gerstner / FFT ocean) — that's a separate `ocean-water` recipe; this is impact ripples on top.
+- The user wants the *whole* water surface to wave (Gerstner / FFT ocean) — that needs an ocean wave shader; this recipe adds impact ripples on top.
 - The user wants a 2D top-down ripple effect on a UI map — use `canvas_item` shader, not this `spatial` one.
-- The user wants splash particles flying upward on impact — pair this with `hit-spark` (recolor blue) for the droplets; this only handles the ring on the surface.
+- The user wants splash particles flying upward on impact — pair this with `vfx-hit-spark` (recolor blue) for the droplets; this only handles the ring on the surface.
 - The user wants the ripple to physically displace floating objects — this is visual only. Use `Area3D` impulses for the simulation side.
 
 ## Recipe