summer-engine 3.3.0 → 3.4.1

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

@@ -11,7 +11,7 @@ paths: ["assets/models/**", "**/*.tscn", "**/*.gd"]
 
 # Prop Model — Generate One Static 3D Prop and Wire It
 
-One prop, one mesh, one MeshInstance3D. This is the bread-and-butter call of the 3D-asset family — most game-world objects are static props. The skill exists to keep two things tight: the **prompt shape** that produces a clean isolated mesh on the first try, and the **wire-in pattern** that gets the asset into the scene without leaving orphans in `res://assets/models/`.
+One prop, one mesh, one MeshInstance3D. Most game-world objects are static props, so this is the most common 3D-asset call. The skill keeps two things tight: the **prompt shape** that produces a clean isolated mesh on the first try, and the **wire-in pattern** that gets the asset into the scene without leaving orphans in `res://assets/models/`.
 
 The backing tool is `summer_generate_3d`. Default model is `hunyuan` (Hunyuan 3D v3.1 Pro — best quality). Use `trellis` when speed matters (Trellis 2 is ~2× faster, slightly lower fidelity). `meshy` is the legacy fallback — only pick it if the user asks by name.
 
@@ -72,7 +72,7 @@ The `isolated object` and `white background` clauses are load-bearing — withou
 
 ### 4. Confirm and call
 
-> About to generate `viking_axe` via `hunyuan`, target ~5k tris. ~$0.50, ~60s. OK?
+> About to generate `viking_axe` via `hunyuan`, target ~5k tris, ~60s. This uses credits. OK?
 
 ```
 summer_generate_3d(
@@ -127,8 +127,8 @@ the parent-shape pattern.
 
 The user can run the same prompt in the Summer dashboard or a supported
 provider UI, download the `.glb`, and drop it into `res://assets/models/`.
-Summer Engine's Import dock will pick it up. Then add a MeshInstance3D and
-assign the mesh.
+Summer Engine's Import dock will pick it up. Then instance the `.glb` scene in
+the level (an imported `.glb` is a scene, not a `Mesh`).
 
 ## Handoff
 

package/library/skills/psx-retro-rendering/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: psx-retro-rendering
-description: "Hardware-informed PlayStation 1 rendering in Godot 4 — low-res output, RGB5 and exact dither, affine textures, vertex snapping, blend modes, fog; limits named."
+description: "PlayStation 1 rendering in Summer Engine — low-res output, RGB5 and exact dither, affine textures, vertex snapping, blend modes, fog; limits named."
 license: MIT
 category: shaders
 tags:
@@ -13,19 +13,19 @@ confidence: extracted
 adaptation: translated
 ---
 
-# PSX Retro Rendering in Godot 4
+# PSX Retro Rendering in Summer Engine
 
 ## Outcome
 
 Recreate the visible behavior of the original PlayStation rendering pipeline while keeping three things distinct:
 
 1. behavior the PS1 actually had;
-2. the Godot technique used to imitate it;
+2. the engine technique used to imitate it;
 3. places where the imitation cannot reproduce the hardware exactly.
 
 The characteristic result comes from several interacting constraints, not from a single fullscreen filter: a low-resolution framebuffer, 5-bit color, conditional polygon dithering, unfiltered affine textures, integer screen-coordinate vertices, CPU-style polygon ordering, vertex colors and lighting, fixed semi-transparency equations, and depth-cued fog.
 
-The article author's MIT-licensed Godot 4 addon is useful implementation evidence:
+The article author's MIT-licensed addon is useful implementation evidence:
 
 - `https://github.com/wyvernbw/godot-psxlike`
 - Treat it as a reference implementation, not as proof that every approximation is hardware-exact, compatible with the current Summer Engine build, or suitable for every scene.
@@ -40,7 +40,7 @@ Do not activate this skill for an ordinary low-resolution or pixel-art presentat
 
 ## Authenticity Boundary
 
-| Visible behavior | Original hardware mechanism | Practical Godot implementation | Accuracy boundary |
+| Visible behavior | Original hardware mechanism | Practical engine implementation | Accuracy boundary |
 |---|---|---|---|
 | Low resolution | 1 MB VRAM shared by framebuffers and textures | Render the root viewport at a PSX-era base size | Does not reproduce the VRAM budget |
 | RGB5 color | GPU draws RGB555 plus one mask bit | Quantize fragment color to 31 levels per channel | Mask-bit write protection is normally omitted |
@@ -48,7 +48,7 @@ Do not activate this skill for an ordinary low-resolution or pixel-art presentat
 | Texture warping | UVs are interpolated affinely | Cancel the GPU's perspective correction with clip `w` | Subdivision strongly changes the result |
 | Vertex wobble | Integer screen coordinates and no subpixel rasterization | Quantize clip/NDC coordinates against the viewport | Do not use an arbitrary object-space grid |
 | Polygon overlap | No hardware Z-buffer; the CPU submits depth-sorted primitives | Flat `DEPTH`, mesh subdivision, and an optional depth bias | Flat depth is only a proxy for draw ordering |
-| Lighting | CPU/GTE-derived colors, Gouraud interpolation | Calculate light at vertices and carry it through `COLOR` | Godot's ordinary per-pixel light pass is different |
+| Lighting | CPU/GTE-derived colors, Gouraud interpolation | Calculate light at vertices and carry it through `COLOR` | The engine's ordinary per-pixel light pass is different |
 | Semi-transparency | Four fixed framebuffer blend equations | Sample the screen texture in a transparent material | Transparent objects cannot reliably blend with each other |
 | Fog | GTE depth cue and color operations | Quantized per-vertex factor plus modulation or a fragment blend | Authentic Silent Hill fog is a two-pass technique |
 
@@ -56,9 +56,9 @@ The PS1 GPU is fundamentally a 2D ordered polygon rasterizer. Avoid saying that
 
 ## Summer Engine Integration
 
-At the pinned Summer Engine revision, `ShaderMaterial` supports shared shaders, material uniforms, and per-instance uniforms through `GeometryInstance3D.set_instance_shader_parameter()`. Prefer per-instance uniforms over duplicating materials when changing mesh-local PSX settings. See `SummerEngine/SummerEngine@a8e5ca520efa927bde6131c9fb36557f19c1bb18:doc/classes/ShaderMaterial.xml`.
+`ShaderMaterial` supports shared shaders, material uniforms, and per-instance uniforms through `GeometryInstance3D.set_instance_shader_parameter()`. Prefer per-instance uniforms over duplicating materials when changing mesh-local PSX settings.
 
-In Summer's material workflow, attach a `.tres` material override to the `MeshInstance3D`, not its parent `Node3D`, and save the scene after assignment. A custom PSX pipeline is an appropriate `ShaderMaterial` use because `StandardMaterial3D` cannot express affine interpolation, screen-coordinate snapping, or fixed framebuffer blend equations. See `SummerEngine/PublicSummerEngine@63f6e5cf71d0ddd5df9092cbbe82fee9b9ecf6c0:skills/look/materials-and-vfx/SKILL.md`.
+In Summer's material workflow, attach a `.tres` material override to the `MeshInstance3D`, not its parent `Node3D`, and save the scene after assignment. A custom PSX pipeline is an appropriate `ShaderMaterial` use because `StandardMaterial3D` cannot express affine interpolation, screen-coordinate snapping, or fixed framebuffer blend equations.
 
 Use this project shape:
 
@@ -84,7 +84,7 @@ Assign the spatial shader material to meshes. A `WorldEnvironment` or camera env
 
 Shared materials, texture arrays, instance uniforms, and Forward+ can improve batching opportunities. They do not guarantee that arbitrary meshes render in one draw call. Transparent and opaque rendering already require separate materials.
 
-Compatibility-sensitive names and shader behavior must be checked against the installed Summer Engine build. The pinned references document the integration surface used for this translation; they are not a permanent API guarantee.
+Check compatibility-sensitive names and shader behavior against the installed Summer Engine build.
 
 ## Agent Procedure
 
@@ -109,7 +109,7 @@ Disable MSAA, TAA, FXAA, texture filtering, and modern post-effects on the PSX p
 
 ### 2. Keep the Color Pipeline Explicit
 
-RGB5 quantization and the PS1 dither operate on display-encoded RGB values, not on linear-light values. Godot's Forward+ color conversions can otherwise change the palette and dither response.
+RGB5 quantization and the PS1 dither operate on display-encoded RGB values, not on linear-light values. The Forward+ color conversions can otherwise change the palette and dither response.
 
 Choose one coherent texture path:
 
@@ -159,7 +159,7 @@ vec3 psx_dither(vec3 color, vec2 fragcoord, bool eligible) {
 }
 ```
 
-On hardware, dithering was selectable per polygon and was available only to Gouraud-shaded or texture-modulated polygons. In a normal Godot mesh shader, a per-mesh instance uniform is a practical compromise:
+On hardware, dithering was selectable per polygon and was available only to Gouraud-shaded or texture-modulated polygons. In a normal mesh shader, a per-mesh instance uniform is a practical compromise:
 
 ```glsl
 bool dither_eligible = shading == SHADING_GOURAUD || use_modulation;
@@ -200,7 +200,7 @@ if (texturing == TEX_TEXTURED && all(equal(color, vec3(0.0)))) {
 
 PS1 polygons can be flat- or Gouraud-shaded, textured or untextured, and raw-textured or texture-modulated. Preserve those as explicit modes.
 
-True per-triangle flat colors are awkward in an ordinary Godot mesh shader. Practical choices are:
+True per-triangle flat colors are awkward in an ordinary mesh shader. Practical choices are:
 
 - use one `flat_color` instance uniform for a whole mesh;
 - duplicate triangle vertices and bake the same color into all three;
@@ -258,7 +258,7 @@ Use the snapped value for `POSITION` and for the clip position carried to the fr
 
 ### 8. Treat Flat Depth as an Approximation
 
-The original GPU drew polygons in submission order. A Godot shader cannot reproduce the CPU ordering table, so the reference shader uses a non-interpolated depth value:
+The original GPU drew polygons in submission order. A spatial shader cannot reproduce the CPU ordering table, so the reference shader uses a non-interpolated depth value:
 
 ```glsl
 varying flat float polygon_depth;
@@ -287,7 +287,7 @@ If exact ordering is a requirement, sort and submit appropriately partitioned ge
 
 On original hardware, the CPU/GTE calculates vertex colors. Normals are not interpolated and lit per fragment. The GTE provides a basic three-light directional model; games can also implement their own point-light logic.
 
-Godot's normal `light()` path is per fragment. Enabling Godot vertex lighting gets closer geometrically, but lighting can be applied after the custom fragment pipeline, which leaves gradients too smooth and bypasses the intended RGB5/dither response.
+The normal `light()` path is per fragment. Enabling vertex lighting gets closer geometrically, but lighting can be applied after the custom fragment pipeline, which leaves gradients too smooth and bypasses the intended RGB5/dither response.
 
 For a consistent result:
 
@@ -314,7 +314,7 @@ For existing framebuffer color `B` and incoming fragment color `F`, support:
 | Subtract | `B - F` |
 | Quarter add | `B + 0.25 * F` |
 
-These are fixed blend modes, not ordinary source-alpha blending. In Godot, screen-texture access moves the material into the transparent pass. Keep common pipeline code in a `.gdshaderinc` file and provide separate opaque and transparent shaders.
+These are fixed blend modes, not ordinary source-alpha blending. Screen-texture access moves the material into the transparent pass. Keep common pipeline code in a `.gdshaderinc` file and provide separate opaque and transparent shaders.
 
 Apply the selected blend before the final dither, RGB5 quantization, and linear conversion:
 
@@ -361,8 +361,8 @@ Preserve these relationships even if the implementation is reorganized:
 - Affine UV compensation multiplies at the vertex and divides after interpolation.
 - Vertex lighting and modulation happen before fragment dithering and quantization.
 - Dithering uses fragment coordinates and precedes RGB5 quantization.
-- RGB5 and dithering operate in sRGB; the final `ALBEDO` is converted to linear for Godot.
-- Flat depth is explicitly labeled as a Godot approximation of ordered drawing.
+- RGB5 and dithering operate in sRGB; the final `ALBEDO` is converted to linear.
+- Flat depth is explicitly labeled as an approximation of ordered drawing.
 - Opaque and transparent materials share code but remain separate render paths.
 - Silent Hill-style single-pass fog is labeled as an approximation if geometry is not actually rendered twice.
 
@@ -390,7 +390,7 @@ Preserve these relationships even if the implementation is reorganized:
 - **Textures explode on large surfaces:** subdivide geometry or reduce grazing camera angles; affine mapping is working but uncontrolled.
 - **A floor covers nearby meshes:** this is a flat-depth proxy failure; subdivide first, then apply a small depth modifier.
 - **Transparent objects do not blend with each other:** this is the screen-texture/transparent-pass limitation.
-- **Lighting gradients look modern and smooth:** Godot's per-fragment lighting is bypassing the custom vertex-color pipeline.
+- **Lighting gradients look modern and smooth:** the engine's per-fragment lighting is bypassing the custom vertex-color pipeline.
 - **Colored modulation fog looks too bright:** modulation is not a conventional color lerp; choose black or use the labeled Silent Hill-style approximation.
 - **Flat fog is excessively patterned:** use an RGB5-representable fog color, dither before quantizing, and quantize with `round()`.
 - **Batching is worse than expected:** different meshes, materials, transparency paths, shader variants, or instance state can split batches; shared materials do not guarantee one draw call.
@@ -406,11 +406,11 @@ Verify the running client, not only shader compilation:
 5. Rotate a large textured quad to expose affine warping, then subdivide it and confirm the distortion decreases.
 6. Overlap intersecting triangles and verify the chosen flat-depth approximation and depth modifiers are understood.
 7. Test raw texture mode, half-gray neutral modulation, and the pure-black transparency rule independently.
-8. Compare a custom vertex-lit mesh against Godot per-pixel lighting and confirm the light gradient passes through dither and RGB5.
+8. Compare a custom vertex-lit mesh against the engine's per-pixel lighting and confirm the light gradient passes through dither and RGB5.
 9. Exercise every transparency equation over known background colors, then separately demonstrate the overlapping-transparent limitation.
 10. Test black modulation fog, colored modulation fog, and the Silent Hill-style approximation at the near and far planes.
 11. Capture the same scene in Compatibility and Forward+ if both are supported; investigate color-space or feature differences rather than assuming parity.
 
 ## Confidence
 
-`extracted` — Hardware mechanisms and the Godot techniques are drawn from Calin P's hardware-informed article and MIT reference addon. The skill explicitly identifies modern approximations and known limitations. It has not been verified end to end inside SummerEngine, so do not label a project `summerengine-verified` until the visible client flow and renderer-specific behavior have been tested.
+`extracted` — Hardware mechanisms and the engine techniques are drawn from Calin P's hardware-informed article and MIT reference addon. The skill explicitly identifies modern approximations and known limitations. It has not been verified end to end inside Summer Engine. Test the visible client flow and renderer-specific behavior before calling a project verified.

package/library/skills/psx-retro-rendering/resource.yaml

@@ -1,7 +1,7 @@
 id: skill/psx-retro-rendering
 kind: skill
 version: 0.1.1
-summary: "Hardware-informed PlayStation 1 rendering in Godot 4 — low-res output, RGB5 and exact dither, affine textures, vertex snapping, blend modes, fog; limits named."
+summary: "PlayStation 1 rendering in Summer Engine — low-res output, RGB5 and exact dither, affine textures, vertex snapping, blend modes, fog; limits named."
 use_when:
   - "make my game render like a PlayStation 1 game, with texture warping, vertex wobble, and dithering"
   - "add a PSX retro shader to the 3D scene"
@@ -10,7 +10,6 @@ use_when:
 do_not_use_when:
   - "an ordinary low-resolution or pixel-art presentation that does not need PS1-specific rendering behavior"
   - "defining the overall visual style, palette, or mood — use art-direction first"
-  - "intake from the gamedev-knowledge pipeline (source-cited, pipeline-validated, not yet exercised in-engine by the Summer team) — verify results in the engine as you would any technique"
 facets:
   lifecycle:
     - build
@@ -33,4 +32,4 @@ status: preview
 recommended: false
 lint_exceptions:
   - url-allowlist
-lint_exception_reason: "Source citation for knowledge extracted by the gamedev-knowledge pipeline: the body links the MIT-licensed godot-psxlike reference addon on GitHub (wyvernbw) that the extracted article names as its implementation evidence. Read-only provenance link; the skill never fetches or installs it."
+lint_exception_reason: "Source citation: the body links the MIT-licensed godot-psxlike reference addon on GitHub (wyvernbw) that the extracted article names as its implementation evidence. Read-only provenance link; the skill never fetches or installs it."

package/library/skills/realtime-wet-surfaces/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: realtime-wet-surfaces
-description: "Real-time wetness on existing Godot 4 materials without losing their values — value-copying wet shader, geometry-driven wet mask, instance-uniform wet amount."
+description: "Real-time wetness on existing materials without losing their values — value-copying wet shader, geometry-driven wet mask, instance-uniform wet amount."
 license: MIT
 category: shaders
 tags:
@@ -12,11 +12,11 @@ tags:
 confidence: extracted
 ---
 
-# Real-Time Wet Surfaces (Value-Preserving Wet Materials in Godot 4)
+# Real-Time Wet Surfaces (Value-Preserving Wet Materials)
 
 ## Outcome
 
-Implement a real-time wetness effect in SummerEngine that can be applied to existing materials **without losing their configured values** (albedo, metallic, roughness, textures). The wet mask is driven by geometry alone (upward-facing surfaces collect wetness first), with a global/per-instance wet amount that can be animated at runtime. This mirrors the Unity architecture described in the source evidence: a pre-configured shader-graph swap that keeps the standard Lit material's values, driven by a CustomFunction bridge.
+Implement a real-time wetness effect in Summer Engine that can be applied to existing materials **without losing their configured values** (albedo, metallic, roughness, textures). The wet mask is driven by geometry alone (upward-facing surfaces collect wetness first), with a global/per-instance wet amount that can be animated at runtime. This follows the source technique: a pre-configured shader swap that keeps the standard material's values, fed by a custom-function bridge.
 
 ## When to Use
 
@@ -28,17 +28,17 @@ Implement a real-time wetness effect in SummerEngine that can be applied to exis
 
 The source technique's key idea is **separation of wetness from material authoring**: the wet logic is a self-contained graph/function that receives material values and injects a wet mask, so enabling wetness is a swap, not a rewrite.
 
-Godot 4 mapping of the Unity concepts:
+How the source concepts map to Summer Engine:
 
-| Unity concept (from source) | Godot 4 equivalent |
+| Source concept | Summer Engine equivalent |
 |---|---|
-| Standard Lit material with retained values | `StandardMaterial3D` values copied into a `ShaderMaterial` by a one-time converter |
-| Pre-configured ShaderGraph swap | Shared wet-enabled `.gdshader`; swap the material once, keep all parameter values |
-| CustomFunction carrying values into the graph | Shader uniforms + instance uniforms (`set_instance_shader_parameter`) or `RenderingServer` global shader parameters for scene-wide wet state |
+| Standard lit material with retained values | `StandardMaterial3D` values copied into a `ShaderMaterial` by a one-time converter |
+| Pre-configured shader-graph swap | Shared wet-enabled `.gdshader`; swap the material once, keep all parameter values |
+| Custom-function node carrying values into the graph | Shader uniforms + instance uniforms (`set_instance_shader_parameter`) or `RenderingServer` global shader parameters for scene-wide wet state |
 | Wet mask from geometry shape alone | Fragment mask from world-space normal up-facing component (`world_normal.y`), optionally broken up by world-position noise |
 | Planned heightmap flow | Sample a heightmap texture and offset the wet mask along its gradient (future extension; not evidenced in source) |
 
-**Important constraint:** Godot cannot inject custom nodes into a `StandardMaterial3D` at runtime. The faithful equivalent of "swap in the pre-configured SG while keeping all values" is a **converter that copies `StandardMaterial3D` parameters into the wet shader** (below). The alternative — leaving `StandardMaterial3D` untouched and overlaying wetness via decals or post-processing — does not match the source's material-preserving architecture and is not recommended here.
+**Constraint:** the engine cannot inject custom nodes into a `StandardMaterial3D` at runtime. The equivalent of "swap in the pre-configured shader while keeping all values" is a **converter that copies `StandardMaterial3D` parameters into the wet shader** (below). The alternative — leaving `StandardMaterial3D` untouched and overlaying wetness via decals or post-processing — does not match the source's material-preserving architecture and is not recommended here.
 
 ## Scene / Node Shape
 
@@ -58,7 +58,7 @@ Scene
 
 ### 1. Write the shared wet-enabled spatial shader
 
-Preserve the PBR parameters as uniforms and compute the wet mask from geometry. In Godot 4, fragment-stage `NORMAL` is **view-space**, so pass a world-space normal from the vertex stage — otherwise the "upward-facing" mask rotates with the camera.
+Preserve the PBR parameters as uniforms and compute the wet mask from geometry. Fragment-stage `NORMAL` is **view-space**, so pass a world-space normal from the vertex stage — otherwise the "upward-facing" mask rotates with the camera.
 
 ```glsl
 shader_type spatial;
@@ -108,7 +108,7 @@ Assumes near-uniform mesh scale; for heavily non-uniform scale, use the inverse-
 
 ### 2. Convert existing materials while preserving their values
 
-This is the Godot equivalent of the source's "swap in the pre-configured SG; all values retained" step. Run once (editor tool or import-time), not per frame.
+This is the source's "swap in the pre-configured shader; all values retained" step. Run once (editor tool or import-time), not per frame.
 
 ```gdscript
 @tool
@@ -150,7 +150,7 @@ Use `Area3D` rain zones to toggle `raining` for objects inside them. For scene-w
 
 ### 4. Planned extension: heightmap-guided flow
 
-The source author states heightmap support so wetness flows along map bumps is **planned, not shipped**. When implementing later in Godot: sample a heightmap texture in the fragment stage and bias the wet mask along its gradient (e.g., offset `world_pos.xz` lookups downhill using the height texture derivatives) so streaks follow surface relief. Do not treat this as part of the evidenced technique.
+The source author states heightmap support so wetness flows along map bumps is **planned, not shipped**. To implement it: sample a heightmap texture in the fragment stage and bias the wet mask along its gradient (e.g., offset `world_pos.xz` lookups downhill using the height texture derivatives) so streaks follow surface relief. Do not treat this as part of the evidenced technique.
 
 ## Tunables
 
@@ -166,7 +166,7 @@ The source author states heightmap support so wetness flows along map bumps is *
 ## Failure Modes & Gotchas
 
 - **View-space normal mistake:** using fragment `NORMAL` directly makes the up-facing mask rotate with the camera. Always pass world normal from `vertex()` via a varying.
-- **Expecting in-place injection:** Godot cannot add wet logic to a live `StandardMaterial3D`. The value-preserving step is the one-time conversion, not runtime patching.
+- **Expecting in-place injection:** the engine cannot add wet logic to a live `StandardMaterial3D`. The value-preserving step is the one-time conversion, not runtime patching.
 - **Duplicate shaders per material:** keep ONE shared `.gdshader`; per-material differences live in uniforms, per-object state in instance uniforms. Otherwise you pay shader compilation and draw-call overhead.
 - **Over-darkening:** on already-dark albedos, clamp the darkened result or lower `darkening`.
 - **Transparent/unshaded materials:** out of scope; this skill targets opaque PBR surfaces.
@@ -182,8 +182,8 @@ The source author states heightmap support so wetness flows along map bumps is *
 
 ## Confidence
 
-`extracted` — the Unity-side architecture (Lit-preserving wet swap, CustomFunction→ShaderGraph value bridge, geometry-only mask, planned heightmap flow) is extracted from the linked X post (see evidence boundaries in the source file: demo video and replies not retrievable, no code published). The Godot 4 mapping, shader, and scripts are librarian engineering guidance consistent with that evidence, **not** source-extracted implementation and **not** verified inside SummerEngine.
+`extracted` — the architecture (material-preserving wet swap, custom-function value bridge, geometry-only mask, planned heightmap flow) comes from a public post that showed the technique in another engine; no code was published. The mapping, shader, and scripts here are engineering guidance consistent with that post, **not** source-extracted implementation and **not** verified inside Summer Engine.
 
 ## Evidence
 
-- Source record `sources/x/tenmomo-unity-realtime-wet/source.md`, kept outside this package (the evidence boundaries above summarise it).
+- A public X post describing the technique (demo video only, no code).

package/library/skills/realtime-wet-surfaces/resource.yaml

@@ -1,7 +1,7 @@
 id: skill/realtime-wet-surfaces
 kind: skill
 version: 0.1.1
-summary: "Real-time wetness on existing Godot 4 materials without losing their values — value-copying wet shader, geometry-driven wet mask, instance-uniform wet amount."
+summary: "Real-time wetness on existing materials without losing their values — value-copying wet shader, geometry-driven wet mask, instance-uniform wet amount."
 use_when:
   - "make surfaces look wet when it rains and dry off afterwards"
   - "add rain wetness to the level without redoing every material"
@@ -9,7 +9,6 @@ use_when:
   - "wet cave, shoreline, or post-rain look on existing PBR materials"
 do_not_use_when:
   - "transparent or unshaded materials, water bodies, or puddle simulation — this targets opaque PBR surfaces"
-  - "intake from the gamedev-knowledge pipeline (source-cited, pipeline-validated, not yet exercised in-engine by the Summer team) — verify results in the engine as you would any technique"
 facets:
   lifecycle:
     - build

package/library/skills/remote-deploy/SKILL.md

@@ -15,15 +15,14 @@ paths: ["project.godot", "export_presets.cfg"]
 
 Remote Deploy runs the game on an actual target device — a phone, tablet, or another machine — instead of inside the editor. It exports a **debug** build, installs and launches it on the device, and connects the running game back to the editor's debugger so the Output panel, errors, breakpoints, and profiler all work exactly like a local run.
 
-**Core principle:** Remote Deploy is "Play, but on the hardware." Same debug loop, real device.
-
 **Capability gate comes first:** before adding a Runnable preset or telling the
-user to pick a device, inventory the exact Summer build's export templates and
-the platform toolchain. A stock Summer 4.6.1 Mono install has only the macOS
-template. It cannot export Web, and Android/iOS/Windows/Linux are unavailable
-until a matching custom template or external build environment is configured.
-Never recommend or attempt a Remote Deploy target that has not passed this
-proof.
+user to pick a device, check the installed Summer Engine's export templates and
+the platform toolchain. Remote Deploy exports a debug build, so it needs the
+debug template for that platform. `summer_export_templates` with
+`action: "list"` shows what is installed and published; `action: "install"`
+with `includeDebug: true` adds missing ones. Android and iOS also need their SDK
+toolchain and signing. Never recommend or attempt a Remote Deploy target that
+has not passed this check.
 
 It is **not** the same as two neighbours:
 
@@ -31,7 +30,7 @@ It is **not** the same as two neighbours:
 |---|---|---|
 | **Play** (▶) | Runs in the editor (embedded or windowed) | Fast iteration on the dev machine |
 | **Remote Deploy** | Debug build → installs + runs on a device, remote-debugged | Testing real input/perf/screen on hardware |
-| **export-and-ship** (`export-and-ship`) | Supported local release builds | Preparing an artifact for a separate user-controlled distribution workflow |
+| **Release export** (`export-and-ship`) | Supported local release builds | Preparing an artifact for a separate user-controlled distribution workflow |
 
 If the user wants a release build for Steam / itch / the App Store, that is `export-and-ship`, not this.
 
@@ -39,22 +38,22 @@ If the user wants a release build for Steam / itch / the App Store, that is `exp
 
 - **Agent-layout topnav:** the button with the remote-play icon, immediately right of the **Play/Stop** button and the **`▾`** run-options dropdown. Hover tooltip reads **"Remote Deploy"**.
 - Clicking it opens a **dropdown of detected targets**, grouped by platform (e.g. an `Android` header with each connected device under it). Picking a target deploys and runs there.
-- It is **disabled (greyed out)** with the tooltip **"No Remote Deploy export presets configured."** until the prerequisites below are met. A greyed button is the #1 thing users ask about — it almost always means "no runnable preset or no device detected," not a bug.
+- It is **disabled (greyed out)** with the tooltip **"No Remote Deploy export presets configured."** until the prerequisites below are met. A greyed button is the most common question; it almost always means "no runnable preset or no device detected," not a bug.
 
 ## Step 1 — prove the requested target is available
 
-Use `summer_get_project_context` to identify the exact engine binary and
-technical base, inspect its matching export-template directory, then check the
-requested platform toolchain. Report one of:
+Run `summer_export_templates` with `action: "list"`, then check the requested
+platform toolchain. Report one of:
 
-- `available`: matching template and toolchain are present;
+- `available`: the matching debug template and toolchain are present;
 - `blocked`: name the missing template, toolchain, signing, or device
   prerequisite;
 - `impossible on this build`: Web on the stock Mono build.
 
-Stop on `blocked` or `impossible`. Route the user to template installation,
-custom-template setup, or an external CI/device workflow. Do not add a preset
-as if that made the target runnable.
+Stop on `impossible`. On `blocked`, install the missing template (`summer_export_templates`
+`action: "install"`, `includeDebug: true`) after the user agrees, or route the
+user to the toolchain setup. Do not add a preset as if that made the target
+runnable.
 
 ## Step 2 — prerequisites for a proven target
 
@@ -66,7 +65,7 @@ The button auto-enables the moment a runnable preset **and** at least one detect
 | A **runnable export preset** for that proven platform | Project → Export → add the proven preset → toggle **Runnable** on | A preset that exists but isn't marked Runnable does **not** count. |
 | A **detected target** | For example, an authorized Android device or a connected, trusted iOS device | The button enables only when at least one target is reported for a runnable platform. |
 
-**Important nuance:** the button does **not** pre-check that templates/toolchain are installed. Enable state is gated only on *runnable preset + detected target*. If templates or the toolchain are missing, the deploy **fails at run time** and the errors appear in a result dialog. So:
+**Note:** the button does **not** pre-check that templates/toolchain are installed. Enable state is gated only on *runnable preset + detected target*. If templates or the toolchain are missing, the deploy **fails at run time** and the errors appear in a result dialog. So:
 
 > **Runnable preset + a detected device make the button appear/enable. Installed export templates make the deploy actually succeed.**
 
@@ -108,9 +107,9 @@ export environment.
 
 When a user says "deploy to my phone" / "run this on device" and the button is greyed:
 
-1. **Prove target capability first** — inspect the exact build's matching
-   template directory and platform toolchain. Stop or route externally if
-   either is absent; Web is impossible on the stock Mono build.
+1. **Prove target capability first** — check the matching debug template
+   (`summer_export_templates`) and the platform toolchain. Stop or route
+   externally if either is absent; Web is impossible on the stock Mono build.
 2. **Check the build is healthy** — a project with script errors won't export.
    - `summer_get_script_errors` and `summer_get_diagnostics` clean? If not, fix those before anything else.
    - `summer_get_console` for "import failed" noise.

package/library/skills/retarget/SKILL.md

@@ -15,19 +15,17 @@ paths: ["**/*.tscn", "**/*.tres"]
 
 Summer ships **no** `summer_retarget_motion` tool, and no other MCP tool that
 re-projects an existing animation asset onto a second rig. Verify it yourself:
-`summer tool --list` prints every registered tool and there is no retarget entry. Never call one — the MCP server rejects
-unknown tool names outright, and inventing a cost table for it ("$0.05 a clip")
-is worse than saying nothing.
+`summer tool --list` prints every registered tool and there is no retarget entry. Never call one: the MCP server rejects
+unknown tool names outright.
 
 Two real paths exist. Pick by whether the target rig is Meshy-rigged.
 
 | Situation | Path |
 |---|---|
-| Target is Meshy-rigged and the clip name is on the curated list | Re-run `summer_generate_motion` against the target's `rigAssetId`. Same clip, ~$0.10, ~30s. |
+| Target is Meshy-rigged and the clip name is on the curated list | Re-run `summer_generate_motion` against the target's `rigAssetId`. Same clip, ~30s, uses credits. |
 | Target is not Meshy-rigged, or the clip is hand-authored / Mixamo / bought | In-engine retargeting: `BoneMap` + `SkeletonProfileHumanoid` + `RetargetModifier3D`. No credits, no network, but you configure the bone mapping. |
 
-The rest of this skill covers both. The cost math that used to live here assumed a
-retarget API that does not exist; the honest math is below.
+The rest of this skill covers both.
 
 ## When to use this skill
 
@@ -65,15 +63,15 @@ summer_search_assets(query: "<target character>", assetType: "3d_model", source:
 ```
 
 Confirm a `rigAssetId` is present. If it is null the model was never rigged —
-stop and propose `summer_generate_3d({ kind: "image-to-3d", imageUrl: "...", options: { rig: true } })`
+stop and propose `summer_generate_3d({ kind: "image-to-3d", imageUrl: "...", rig: true })`
 first, or route to `asset-strategy`.
 
 ### 3. Confirm with user before spending
 
-Regeneration is a real generation per clip per character. Say the total.
+Regeneration is a real generation per clip per character, and each one uses credits. Say the total count.
 
-> I'm about to generate 12 clips (idle, walk, run, attack, ...) on `orc_rigged` —
-> 12 × ~$0.10 = ~$1.20, a few minutes total. OK?
+> I'm about to generate 12 clips (idle, walk, run, attack, ...) on `orc_rigged`.
+> That is 12 generations, a few minutes total. OK?
 
 ### 4. Loop the generation calls
 
@@ -107,9 +105,8 @@ summer_set_resource_property(
 
 ## Path B — in-engine retargeting (non-Meshy rigs, bought or hand-authored clips)
 
-The current Summer Engine build ships the retargeting stack that the MCP layer
-does not wrap. Verified
-instantiable on the shipped binary: `BoneMap`, `SkeletonProfileHumanoid`
+The current Summer Engine build ships a retargeting stack that the MCP layer
+does not wrap. Verified instantiable on the shipped binary: `BoneMap`, `SkeletonProfileHumanoid`
 (56 bones), `RetargetModifier3D`.
 
 The shape:
@@ -129,23 +126,23 @@ skeleton, once.
 
 ## Confirmation gates
 
-- **Before any generation call:** show the full clip list and total cost.
+- **Before any generation call:** show the full clip list and the number of generations.
 - **After the first clip:** preview the result. If it looks wrong, stop the loop
   and re-evaluate (proportions, T-pose, missing bones).
 - **Before saving the scene:** confirm the AnimationPlayer additions you're about to write.
 
 ## Reference card
 
-### Cost math (decision rule)
+### Decision rule
 
-There is no cheaper "retarget" rate to compare against, so the real decision is
-generate-per-character versus spend the time on a `BoneMap`.
+The real decision is generating per character versus spending the time on a
+`BoneMap`.
 
 | Scenario | Regenerate (Path A) | In-engine BoneMap (Path B) |
 |---|---|---|
-| 1 character, 12 clips | ~$1.20 | n/a — nothing to share yet |
-| 5 characters, same 12 clips | ~$6.00 | $0, plus ~1 bone-map pass per distinct skeleton |
-| 30 NPCs sharing one skeleton | ~$36.00 | $0 — same rig, so the clips already play on all of them |
+| 1 character, 12 clips | 12 generations | n/a — nothing to share yet |
+| 5 characters, same 12 clips | 60 generations | No credits, plus ~1 bone-map pass per distinct skeleton |
+| 30 NPCs sharing one skeleton | 360 generations | No credits — same rig, so the clips already play on all of them |
 
 Note the case that makes most of this moot: **NPCs that share one rig share one
 animation library already.** If the user's 30 enemies are 30 instances of the
@@ -177,7 +174,6 @@ same rigged `.glb`, nothing needs retargeting — instance the scene.
 ## Anti-patterns
 
 - Calling a `summer_retarget_motion` / `summer_retarget_*` tool. None exists.
-- Quoting a retarget price. There is no retarget SKU to price.
 - Passing an asset ID to `summer_inspect_resource`. That tool takes a `res://`
   **path** to a resource in the project, not a cloud asset ID. Use
   `summer_get_asset(assetId: ...)` for asset metadata.
@@ -191,7 +187,7 @@ same rigged `.glb`, nothing needs retargeting — instance the scene.
   to re-author per character.
 - **Target rig is a different Meshy skeleton generation.** Symptom: bone-count
   mismatch even though both are Meshy. Re-rig the target with a fresh
-  `summer_generate_3d({ kind: "image-to-3d", options: { rig: true } })` call.
+  `summer_generate_3d({ kind: "image-to-3d", rig: true })` call.
 - **The clip the user wants is not on the curated list.** Path A cannot produce
   it. Either hand-author it, or import a Mixamo clip and take Path B.
 
@@ -201,7 +197,7 @@ Path B is the fallback and does not need MCP at all. In Summer Engine: select
 the source `.glb` in the FileSystem dock, open the Import tab, create/assign a
 `BoneMap` with a `SkeletonProfileHumanoid` profile, re-import. On the target
 character add a `RetargetModifier3D` under `Skeleton3D` with the same profile.
-Documented in the Godot 4.x "Retargeting 3D Skeletons" docs.
+The upstream engine docs cover this under "Retargeting 3D Skeletons".
 
 ## Handoff
 

package/library/skills/running-in-the-cloud/SKILL.md

@@ -7,7 +7,7 @@ description: "Run Summer Engine on a Linux box with no display — install it, l
 
 ## Overview
 
-Summer Engine runs fine on a Linux machine with no display and no human. Everything in this skill was measured in a real cloud container: headless engine boots, MCP tools answer, and renders work under xvfb + llvmpipe.
+Summer Engine runs on a Linux machine with no display and no human. Everything in this skill was measured in a real cloud container: headless engine boots, MCP tools answer, and renders work under xvfb + llvmpipe.
 
 Three facts carry the whole setup:
 
@@ -21,14 +21,14 @@ Three facts carry the whole setup:
 
 | Priority | Source | When |
 |---|---|---|
-| 1 | `SUMMER_ENGINE_BINARY=<abs path>` | The container already carries a prebuilt engine binary (for example a source build's `bin/godot.linuxbsd.editor.x86_64`). Registers that binary — no download. |
+| 1 | `SUMMER_ENGINE_BINARY=<abs path>` | The container already carries a prebuilt engine binary. Registers that binary — no download. |
 | 2 | `SUMMER_ENGINE_URL=<url>` | Download any artifact URL: `.tar.gz`, `.zip`, or a raw executable. |
 | 3 | (default) | The newest published Linux release artifact (`Summer-linux-x86_64-<tag>.tar.gz`). |
 
 All three register the binary at `~/.summer/engine/summer-linux-x86_64`, which is where `summer run` and `summer doctor` look. `SUMMER_ENGINE_BINARY` is also honored directly at lookup time, so setting the env var alone (without ever running `summer install`) is enough for `summer doctor` to report the engine as installed.
 
 ```bash
-# Container with a prebuilt binary — today's cloud unlock:
+# Container with a prebuilt binary:
 export SUMMER_ENGINE_BINARY=/abs/path/to/engine-binary
 summer install      # registers it; summer doctor now shows Engine: ok
 ```
@@ -68,7 +68,7 @@ apt-get install -y xvfb libgl1-mesa-dri   # names vary by distro
 xvfb-run -a <engine-binary> --path <project-dir> --rendering-driver opengl3 ...
 ```
 
-Honest limitations:
+Limitations:
 
 - **No Vulkan in most containers** → Forward+/Mobile renderers are unavailable; you get software GL (Compatibility). Colors and composition are trustworthy; GPU-specific effects, performance numbers, and driver-dependent output are not.
 - Software rendering is slow. Budget seconds per frame, not milliseconds, and never quote FPS measured this way.
@@ -100,4 +100,4 @@ Treat it as a secret: env-inject it from the runner's secret store, never bake i
 **Related skills:**
 - `headless-scripting` — the headless invocation contract, exit-code traps, and what scripts unlock.
 - `playtesting-a-feature` — the verify instance and probes (run them under xvfb in the cloud).
-- `verification-before-completion` — judging work by artifacts, which matters double when nobody can see a screen.
+- `verification-before-completion` — judging work by artifacts, which matters more when nobody can see a screen.

package/library/skills/scene-composition/SKILL.md

@@ -113,7 +113,7 @@ screenshot alone.
 
 1. **Wrong parent path:** `./NonExistent` fails. Ensure the parent exists before adding children.
 2. **Unnamed scene:** Saving without a path fails if the scene was never saved. Use `path` for new scenes.
-3. **Duplicate names:** Godot auto-renames (Node, Node2, etc.). Use descriptive unique names.
+3. **Duplicate names:** the engine auto-renames (Node, Node2, etc.). Use descriptive unique names.
 4. **Mixing 2D and 3D:** Don't put Node2D under Node3D or vice versa in the same hierarchy.
 
 ## Fallback
@@ -121,7 +121,7 @@ screenshot alone.
 MCP is the preferred path, not a requirement. Hand-written `.tscn` text loads and
 instantiates fine — including `[ext_resource]` lines with **no `uid=` field**,
 which the engine resolves by path (verified by loading such a scene on the
-shipped 4.6.1 build). Format version 3 is current for Godot 4.
+shipped 4.6.1 build). Format version 3 is current.
 
 What actually goes wrong when you hand-write scenes is mundane and checkable:
 a `SubResource("id")` with no matching `[sub_resource id="id"]` block, a
@@ -146,7 +146,7 @@ Rule when copying a scene as a template:
 
 ## Trap — Third-person camera collision when foliage shouldn't block
 
-Godot's `SpringArm3D` shortens the camera boom when it raycasts into geometry on the configured `collision_mask`. If your trees, bushes, or grass have collision so the player physically bumps them, on the same layer the SpringArm queries, the camera shortens for foliage too. Players see the camera awkwardly snap forward whenever they walk near a tree.
+`SpringArm3D` shortens the camera boom when it raycasts into geometry on the configured `collision_mask`. If your trees, bushes, or grass have collision so the player physically bumps them, on the same layer the SpringArm queries, the camera shortens for foliage too. Players see the camera awkwardly snap forward whenever they walk near a tree.
 
 The pattern that works:
 
@@ -156,9 +156,9 @@ The pattern that works:
    - Player `CharacterBody3D`: `collision_mask = 259` (which is 1 + 2 + 256, Entities + Level + Foliage).
 3. SpringArm uses a mask that catches solid level geometry but excludes foliage.
    - SpringArm: `collision_mask = 3` (which is 1 + 2, Entities + Level only).
-4. For the visual fade the user expects when the camera is "behind" a tree, add the foliage mesh to the `camera_fade` group. An existing camera-occlusion fade system can ghost the mesh by AABB intersection with the camera-to-player segment without touching collision.
+4. For the visual fade the user expects when the camera is "behind" a tree, use a camera-occlusion fade instead of collision: if the project has one, add the foliage mesh to its group (for example `camera_fade`) so it ghosts the mesh when it crosses the camera-to-player segment.
 
-Why per-layer split: there's no clean way to exclude a single body type from `SpringArm3D`'s collision check via `add_excluded_object` for dynamically-spawned foliage. You'd have to register every tree at spawn time and re-register on level change. Layer-level filtering is set-and-forget.
+Why per-layer split: there's no clean way to exclude a single body type from `SpringArm3D`'s collision check via `add_excluded_object` for dynamically-spawned foliage. You'd have to register every tree at spawn time and re-register on level change. Layer filtering needs no upkeep.
 
 Don't skip the player mask update. If you only move foliage to layer 9 without adding it to the player's mask, the player walks straight through trees.