Release 1.1.2 — the default path works end to end

Fix release for 1.1.1: the minimal path end to end, engine commands that
run on Godot, Unity and Unreal, hook warnings you can see, and verdicts
that say when they could not check. Details in CHANGELOG.md; upgrade
steps in UPGRADING.md (v1.1.1 → v1.1.2).

Fixes #67
Fixes #131

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WuJn2FdynEybfL5KC697nJ

CCGS Skill Testing Framework/agents/engine/godot/godot-csharp-specialist.md

@@ -3,7 +3,6 @@
 ## Agent Summary
 Domain: C# patterns in Godot 4, .NET idioms applied to Godot, [Export] attribute usage, signal delegates, and async/await patterns.
 Does NOT own: GDScript code (gdscript-specialist), GDExtension C/C++ bindings (gdextension-specialist).
-Model tier: Sonnet (default).
 No gate IDs assigned.
 
 ---
@@ -11,8 +10,8 @@ No gate IDs assigned.
 ## Static Assertions (Structural)
 
 - [ ] `description:` field is present and domain-specific (references C# in Godot 4 / .NET patterns / signal delegates)
-- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep
-- [ ] Model tier is Sonnet (default for specialists)
+- [ ] `tools:` list includes Read, Write, Edit, Bash, Glob, Grep
+- [ ] Model tier is `sonnet` — frontmatter `model:` reads exactly `sonnet` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition does not claim authority over GDScript or GDExtension code
 
 ---
@@ -34,7 +33,7 @@ No gate IDs assigned.
 - Does NOT produce GDScript code
 - Explicitly states that GDScript authoring belongs to `godot-gdscript-specialist`
 - Redirects the request to `godot-gdscript-specialist`
-- May note that the C# interface can be described so the gdscript-specialist knows the expected API shape
+- Any hand-off it offers describes the existing C# system's API (its signals and public methods) for godot-gdscript-specialist to port — it contains no GDScript
 
 ### Case 3: Async signal awaiting
 **Input:** "Wait for an animation to finish before transitioning game state using C# async."
@@ -43,7 +42,8 @@ No gate IDs assigned.
 - Uses `await ToSignal(animationPlayer, AnimationPlayer.SignalName.AnimationFinished)`
 - Does NOT use `Thread.Sleep()` or `Task.Delay()` as a polling substitute
 - Notes that the calling method must be `async` and that fire-and-forget `async void` is only acceptable for event handlers
-- Handles cancellation or timeout if the animation could fail to fire
+- Checks `IsInstanceValid(this)` after the `await` before transitioning state — the node may have been freed while waiting
+- If the animation might never finish (interrupted, replaced), raises that as an unspecified edge case for the user to decide; any timeout it adds uses `GetTree().CreateTimer()`, never `Task.Delay()`
 
 ### Case 4: Threading model conflict
 **Input:** "This C# code accesses a Godot Node from a background Task thread to update its position."
@@ -51,7 +51,7 @@ No gate IDs assigned.
 - Flags this as a race condition risk: Godot nodes are not thread-safe and must only be accessed from the main thread
 - Does NOT approve or implement the multi-threaded node access pattern
 - Provides the correct pattern: use `CallDeferred()`, `Callable.From().CallDeferred()`, or marshal back to the main thread via a thread-safe queue
-- Explains the distinction between Godot's main thread requirement and .NET's thread-agnostic types
+- Explains why the code compiles yet is unsafe: the `Task` body runs on a .NET thread-pool thread and nothing in C# stops it touching a Node — the main-thread rule belongs to Godot's scene tree
 
 ### Case 5: Context pass — Godot 4.6 API correctness
 **Input:** Engine version context: Godot 4.6. Request: "Connect a signal using the new typed signal delegate pattern."
@@ -72,6 +72,7 @@ No gate IDs assigned.
 - [ ] Flags multi-threaded Godot node access as unsafe and provides the correct pattern
 - [ ] Uses typed signal delegates — not deprecated string-based Connect() calls
 - [ ] Checks engine version reference for API changes before producing code
+- [ ] Asks "May I write this to [filepath]?" naming the file before writing
 
 ---
 

CCGS Skill Testing Framework/agents/engine/godot/godot-gdextension-specialist.md

@@ -3,7 +3,6 @@
 ## Agent Summary
 Domain: GDExtension API, godot-cpp C++ bindings, godot-rust bindings, native library integration, and native performance optimization.
 Does NOT own: GDScript code (gdscript-specialist), shader code (godot-shader-specialist).
-Model tier: Sonnet (default).
 No gate IDs assigned.
 
 ---
@@ -11,8 +10,8 @@ No gate IDs assigned.
 ## Static Assertions (Structural)
 
 - [ ] `description:` field is present and domain-specific (references GDExtension / godot-cpp / native bindings)
-- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep
-- [ ] Model tier is Sonnet (default for specialists)
+- [ ] `tools:` list includes Read, Write, Edit, Bash, Glob, Grep
+- [ ] Model tier is `sonnet` — frontmatter `model:` reads exactly `sonnet` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition does not claim authority over GDScript or shader authoring
 
 ---
@@ -26,7 +25,7 @@ No gate IDs assigned.
   - Class inheriting from `godot::Object` or an appropriate Godot base class
   - `GDCLASS` macro registration
   - `_bind_methods()` implementation exposing the physics API to GDScript
-  - `GDExtension` entry point (`gdextension_init`) setup
+  - Module entry point: `initialize_module` in `register_types.cpp` registers the class with `ClassDB::register_class<T>()` at `MODULE_INITIALIZATION_LEVEL_SCENE`, reached from the exported init function named by the manifest's `entry_symbol`
 - Notes the `.gdextension` manifest file format required
 - Does NOT produce the GDScript usage code (that belongs to gdscript-specialist)
 
@@ -36,16 +35,16 @@ No gate IDs assigned.
 - Does NOT produce GDScript code
 - Explicitly states that GDScript authoring belongs to `godot-gdscript-specialist`
 - Redirects to `godot-gdscript-specialist`
-- May describe the API surface the GDScript should call (method names, parameter types) as a handoff spec
+- Any hand-off it offers is the extension's bound API surface (method names, parameter and return types) — not GDScript that calls it
 
 ### Case 3: ABI compatibility risk — minor version update
 **Input:** "We're upgrading from Godot 4.5 to 4.6. Will our existing GDExtension still work?"
 **Expected behavior:**
-- Flags the ABI compatibility concern: GDExtension binaries may not be ABI-compatible across minor versions
+- States the compatibility direction: an extension built for 4.5 should load in 4.6, but not the reverse — so it may keep working, yet it must be re-tested, and rebuilt against 4.6 to use newer APIs
 - Directs to check the 4.5→4.6 migration guide for GDExtension API changes
-- Recommends recompiling the extension against the 4.6 godot-cpp headers rather than assuming binary compatibility
+- Recommends rebuilding against the 4.6 godot-cpp headers rather than treating "should load" as tested
 - Notes that the `.gdextension` manifest may need a `compatibility_minimum` version update
-- Provides the recompilation checklist
+- Lays out the rebuild as a checklist: rebuild debug and release (`scons ... target=template_debug` / `template_release`, or `cargo build` / `cargo build --release`) for every target platform, update `compatibility_minimum`, then re-test in the 4.6 editor before shipping
 
 ### Case 4: Memory management — RAII for Godot objects
 **Input:** "How should we manage the lifecycle of Godot objects created inside C++ GDExtension code?"
@@ -55,14 +54,14 @@ No gate IDs assigned.
   - `memnew()` / `memdelete()` for non-reference-counted objects
   - Warning: do NOT use `new`/`delete` for Godot objects — undefined behavior
 - Notes object ownership rules: who is responsible for freeing a node added to the scene tree
-- Provides a concrete example managing a `CollisionShape3D` created in C++
+- Its concrete example (e.g., a `CollisionShape3D` created in C++) applies both rules: the node is created with `memnew()` and handed to the scene tree with `add_child()`, after which the tree frees it (no `memdelete()`); its shape resource is held in a `Ref<>`; `memdelete()` is only for a node that never enters the tree
 
 ### Case 5: Context pass — Godot 4.6 GDExtension API check
 **Input:** Engine version context: Godot 4.6 (upgrading from 4.5). Request: "Check if any GDExtension APIs changed from 4.5 to 4.6."
 **Expected behavior:**
 - References the 4.5→4.6 migration guide from the VERSION.md verified sources list
-- Reports on any documented GDExtension API changes in the 4.6 release
-- If no breaking changes are documented for GDExtension in 4.6, states that explicitly with the caveat to verify against the official changelog
+- Reads the 4.5 → 4.6 table in `docs/engine-reference/godot/breaking-changes.md` and states explicitly that it has no GDExtension-specific row, with the caveat to verify against the official changelog
+- Still surfaces the listed 4.6 changes that reach native code: `Quaternion` now initializes to identity (it was zero)
 - Flags the D3D12 default on Windows (4.6 change) as potentially relevant for GDExtension rendering code
 - Provides a checklist of what to verify after upgrading
 
@@ -74,9 +73,10 @@ No gate IDs assigned.
 - [ ] Redirects GDScript authoring to godot-gdscript-specialist
 - [ ] Redirects shader authoring to godot-shader-specialist
 - [ ] Returns structured output (binding patterns, RAII examples, ABI checklists)
-- [ ] Flags ABI compatibility risks on minor version upgrades — never assumes binary compatibility
+- [ ] States that compatibility runs forward only (older build → newer Godot) and requires a re-test after an upgrade — never treats "should load" as tested
 - [ ] Uses Godot-specific memory management (`memnew`/`memdelete`, `Ref<T>`) not raw C++ new/delete
 - [ ] Checks engine version reference for GDExtension API changes before confirming compatibility
+- [ ] Asks "May I write this to [filepath]?" naming the file before writing
 
 ---
 

CCGS Skill Testing Framework/agents/engine/godot/godot-gdscript-specialist.md

@@ -3,7 +3,6 @@
 ## Agent Summary
 Domain: GDScript static typing, design patterns in GDScript, signal architecture, coroutine/await patterns, and GDScript performance.
 Does NOT own: shader code (godot-shader-specialist), GDExtension bindings (godot-gdextension-specialist).
-Model tier: Sonnet (default).
 No gate IDs assigned.
 
 ---
@@ -11,8 +10,8 @@ No gate IDs assigned.
 ## Static Assertions (Structural)
 
 - [ ] `description:` field is present and domain-specific (references GDScript / static typing / signals / coroutines)
-- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep
-- [ ] Model tier is Sonnet (default for specialists)
+- [ ] `tools:` list includes Read, Write, Edit, Bash, Glob, Grep
+- [ ] Model tier is `sonnet` — frontmatter `model:` reads exactly `sonnet` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition does not claim authority over shader code or GDExtension
 
 ---
@@ -34,33 +33,34 @@ No gate IDs assigned.
 - Does NOT produce shader code in GDScript or in Godot's shading language
 - Explicitly states that shader authoring belongs to `godot-shader-specialist`
 - Redirects the request to `godot-shader-specialist`
-- May note that the GDScript side (passing uniforms to a shader, setting shader parameters) is within its domain
+- Any help it offers stays on the script side its redirect line says it owns (`set_shader_parameter()`, material assignment) — it writes no shader code
 
 ### Case 3: Async loading with coroutines
 **Input:** "Load a scene asynchronously and wait for it to finish before spawning it."
 **Expected behavior:**
 - Produces an `await` + `ResourceLoader.load_threaded_request` pattern for Godot 4
 - Uses static typing throughout (`var scene: PackedScene`)
-- Handles the completion check with `ResourceLoader.load_threaded_get_status()`
+- Handles the completion check with `ResourceLoader.load_threaded_get_status()`, awaiting between polls rather than blocking the frame
+- Checks `is_instance_valid(self)` after the await before spawning — the node may have been freed while the scene loaded
 - Notes error handling for failed loads
 - Does NOT use deprecated Godot 3 `yield()` syntax
 
 ### Case 4: Performance issue — typed array recommendation
 **Input:** "The entity update loop is slow; it iterates an untyped Array of 1,000 nodes every frame."
 **Expected behavior:**
-- Identifies that an untyped `Array` foregoes compiler optimization in GDScript
-- Recommends converting to a typed array (`Array[Node]` or the specific type) to enable JIT hints
-- Notes that if this is still insufficient, escalates the hot path to C# migration recommendation
+- Identifies that an untyped `Array` foregoes GDScript compiler optimizations
+- Recommends converting to a typed array (`Array[Node]` or the specific type) so the compiler can use typed code paths
 - Produces the typed array refactor as the immediate fix
-- Does NOT recommend migrating the entire codebase to C# without profiling evidence
+- Notes that if profiling still shows the loop as a bottleneck, the next step is moving the hot path to GDExtension (C++/Rust) with godot-gdextension-specialist, per its GDScript/GDExtension boundary
+- Does NOT recommend moving the loop, or the codebase, out of GDScript without profiler evidence
 
 ### Case 5: Context pass — Godot 4.6 with post-cutoff features
 **Input:** Engine version context provided: Godot 4.6. Request: "Create an abstract base class for all enemy types using @abstract."
 **Expected behavior:**
 - Identifies `@abstract` as a Godot 4.5+ feature (post-cutoff)
-- Notes this in the output: feature introduced in 4.5, verified against VERSION.md migration notes
-- Produces the GDScript class using `@abstract` with correct syntax as documented in migration notes
-- Marks the output as requiring verification against the official 4.5 release notes due to post-cutoff status
+- Notes this in the output: feature introduced in 4.5, confirmed against `docs/engine-reference/godot/breaking-changes.md` (4.4 → 4.5 table)
+- Produces the GDScript class using `@abstract` on the class and its abstract methods, following the reference docs (`current-best-practices.md`) rather than training data
+- Flags that `VERSION.md` records `Installed at pin time` as NOT DETERMINED — the installed editor must be 4.5 or later for `@abstract` to parse
 - Uses static typing for all method signatures in the abstract class
 
 ---
@@ -73,6 +73,7 @@ No gate IDs assigned.
 - [ ] Returns structured GDScript output with full static typing
 - [ ] Uses Godot 4 API only — no deprecated Godot 3 patterns (yield, connect with strings, etc.)
 - [ ] Flags post-cutoff features (4.4, 4.5, 4.6) and marks them as requiring doc verification
+- [ ] Asks "May I write this to [filepath]?" naming the file before writing
 
 ---
 

CCGS Skill Testing Framework/agents/engine/godot/godot-shader-specialist.md

@@ -3,7 +3,6 @@
 ## Agent Summary
 Domain: Godot shading language (GLSL-derivative), visual shaders (VisualShader graph), material setup, particle shaders, and post-processing effects.
 Does NOT own: gameplay code, art style direction.
-Model tier: Sonnet (default).
 No gate IDs assigned.
 
 ---
@@ -11,8 +10,8 @@ No gate IDs assigned.
 ## Static Assertions (Structural)
 
 - [ ] `description:` field is present and domain-specific (references Godot shading language / materials / post-processing)
-- [ ] `allowed-tools:` list includes Read, Write, Edit, Glob, Grep
-- [ ] Model tier is Sonnet (default for specialists)
+- [ ] `tools:` list includes Read, Write, Edit, Glob, Grep
+- [ ] Model tier is `sonnet` — frontmatter `model:` reads exactly `sonnet` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition references `docs/engine-reference/godot/VERSION.md` as the authoritative source for Godot shader API changes
 
 ---
@@ -34,26 +33,26 @@ No gate IDs assigned.
 **Input:** "Write an HLSL compute shader for this dissolve effect."
 **Expected behavior:**
 - Does NOT produce HLSL code
-- Clearly states: "Godot does not use HLSL directly; it uses its own shading language (a GLSL derivative)"
-- Translates the HLSL intent to the equivalent Godot shader approach
-- Notes that RenderingDevice compute shaders are available in Godot 4 but are a low-level API and flags it appropriately if that was the intent
+- States that Godot materials are written in Godot's own shading language (`.gdshader`, a GLSL derivative), not HLSL
+- Translates the HLSL intent into the equivalent `.gdshader` approach (noise threshold, `discard`, emission at the dissolve edge)
+- If a compute shader was really the intent, flags compute as a separate low-level path (RenderingDevice; unavailable on the Compatibility renderer) and brings in godot-gdextension-specialist for compute-shader offloading
 
-### Case 3: Post-cutoff API change — texture sampling (Godot 4.4)
+### Case 3: Post-cutoff API change — shader texture types (Godot 4.4)
 **Input:** "Use `texture()` with a sampler2D to sample the noise texture in the shader."
 **Expected behavior:**
-- Checks the version reference: Godot 4.4 changed texture sampler type declarations
-- Flags the potential API change: `sampler2D` syntax and `texture()` call behavior may differ from pre-4.4
-- Provides the correct syntax for the project's pinned version (4.6) as documented in migration notes
-- Does NOT use pre-4.4 texture sampling syntax without flagging the version risk
+- Checks the version reference before writing the shader (`VERSION.md`, then `breaking-changes.md` and `modules/rendering.md`)
+- Identifies what the 4.4 change covers: engine-side shader texture parameter/return types moved from `Texture2D` to `Texture` — script and engine API code that handles shader textures, not shading-language syntax
+- Uses `uniform sampler2D noise_texture;` with `texture(noise_texture, UV)` — the form its own patterns use; the reference records no change to shading-language sampling syntax
+- Does NOT invent a changed sampling syntax for 4.4–4.6, or rewrite `sampler2D` / `texture()` because of the 4.4 row
 
 ### Case 4: Fragment shader LOD strategy
 **Input:** "The fragment shader for the water surface has 8 texture samples and is causing GPU bottlenecks on mid-range hardware."
 **Expected behavior:**
 - Identifies the per-fragment texture sample count as the primary cost driver
 - Proposes an LOD strategy:
-  - Reduce sample count at distance (distance-based shader variant or LOD level)
-  - Pre-bake some texture combinations offline
-  - Use lower-resolution noise textures for distant samples
+  - Reduce sample count at distance with a simplified LOD material for distant water, not a per-pixel distance branch in the fragment shader
+  - Move UV/scroll math that does not need per-pixel evaluation into the vertex shader and pass it through a `varying`
+  - Make sure the water textures are mipmapped (e.g. `filter_linear_mipmap`) so distant samples read smaller mip levels
 - Provides the shader code modification implementing the LOD approach
 - Does NOT change gameplay behavior of the water system
 
@@ -61,8 +60,10 @@ No gate IDs assigned.
 **Input:** Engine version context: Godot 4.6. Request: "Add a bloom/glow post-processing effect to the scene."
 **Expected behavior:**
 - References the VERSION.md note: Godot 4.6 includes a glow rework
-- Produces glow configuration guidance using the 4.6 WorldEnvironment approach, not the pre-4.6 API
-- Explicitly notes which properties or parameters changed in the 4.6 glow rework
+- Because `VERSION.md` records `Installed at pin time` as NOT DETERMINED, asks which editor version is installed before tuning for the 4.6 glow behavior
+- Produces glow configuration guidance on the `WorldEnvironment` node's `Environment` resource
+- States the documented 4.6 change: glow now processes before tonemapping (it was after), with screen blending — so glow intensity/blend tuned on an earlier version will look different and may need re-tuning
+- Does NOT invent renamed or removed glow properties that `breaking-changes.md` and `modules/rendering.md` do not document
 - Flags any properties that the LLM's training data may have incorrect information about due to the post-cutoff timing
 
 ---
@@ -71,14 +72,15 @@ No gate IDs assigned.
 
 - [ ] Stays within declared domain (Godot shading language, materials, VFX shaders, post-processing)
 - [ ] Redirects gameplay code requests to gameplay-programmer
-- [ ] Produces valid Godot shading language — never HLSL or raw GLSL without a Godot wrapper
+- [ ] Writes material and post-process shaders as `.gdshader` (Godot shading language) — never HLSL
 - [ ] Checks engine version reference for post-cutoff shader API changes (4.4 texture types, 4.6 glow rework)
 - [ ] Returns structured output (shader code with uniforms documented, LOD strategies with performance rationale)
 - [ ] Flags any post-cutoff API usage as requiring verification
+- [ ] Asks "May I write this to [filepath]?" naming the file before writing
 
 ---
 
 ## Coverage Notes
 - Dissolve shader (Case 1) should be paired with a visual test screenshot in `production/qa/evidence/`
-- Texture API flag (Case 3) confirms the agent checks VERSION.md before using APIs that changed post-4.3
+- Texture-type case (Case 3) confirms the agent reads what a post-cutoff change actually covers before applying it, instead of rewriting syntax the change does not touch
 - Glow rework (Case 5) is a Godot 4.6-specific test — verifies the agent applies the most recent migration notes

CCGS Skill Testing Framework/agents/engine/godot/godot-specialist.md

@@ -3,7 +3,6 @@
 ## Agent Summary
 Domain: Godot-specific patterns, node/scene architecture, signals, resources, and GDScript vs C# vs GDExtension decisions.
 Does NOT own: actual code authoring in a specific language (delegates to language sub-specialists).
-Model tier: Sonnet (default).
 No gate IDs assigned.
 
 ---
@@ -11,8 +10,8 @@ No gate IDs assigned.
 ## Static Assertions (Structural)
 
 - [ ] `description:` field is present and domain-specific (references Godot architecture / node patterns / engine decisions)
-- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep
-- [ ] Model tier is Sonnet (default for specialists)
+- [ ] `tools:` list includes Read, Write, Edit, Bash, Glob, Grep
+- [ ] Model tier is `inherit` — frontmatter `model:` reads exactly `inherit` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition references `docs/engine-reference/godot/VERSION.md` as the authoritative API source
 
 ---
@@ -25,25 +24,28 @@ No gate IDs assigned.
 - Produces a pattern decision guide with rationale:
   - Signals: decoupled communication, parent-to-child ignorance, event-driven UI updates, one-to-many notification
   - Direct calls: tightly-coupled systems where the caller needs a return value, or performance-critical hot paths
-- Provides concrete examples of each pattern in the project's context
+- Illustrates each side with a concrete Godot case (e.g., a child health component emitting a typed `health_changed` signal that its parent or the HUD listens to; a parent calling a method on a child it owns)
 - Does NOT produce raw code for both patterns — refers to gdscript-specialist or csharp-specialist for implementation
-- Notes the "no upward signals" convention (child does not call parent methods directly — uses signals instead)
+- Notes the "call down, signal up" convention: a child does not call its parent's methods directly — it emits a signal — so each scene stays self-contained with no implicit dependency on its parent
 
 ### Case 2: Wrong-engine redirect
 **Input:** "Write a MonoBehaviour that runs on Start() and subscribes to a UnityEvent."
 **Expected behavior:**
 - Does NOT produce Unity MonoBehaviour code
 - Clearly identifies that this is a Unity pattern, not a Godot pattern
-- Provides the Godot equivalent: a Node script using `_ready()` instead of `Start()`, and Godot signals instead of UnityEvent
-- Confirms the project is Godot-based and redirects the conceptual mapping
+- Maps the concepts to Godot: `_ready()` instead of `Start()`, and a typed Godot `signal` connected in `_ready()` instead of a UnityEvent
+- Grounds the answer in the project's engine pin (`docs/engine-reference/godot/VERSION.md`, Godot 4.6) rather than asking which engine the project uses
+- Routes the actual node script to godot-gdscript-specialist or godot-csharp-specialist rather than writing it itself
+- Variant: with `engine.name: Unity` in `project.yaml`, it says it is the wrong specialist for this project instead of mapping the concepts
 
 ### Case 3: Post-cutoff API risk
 **Input:** "Use the new Godot 4.5 @abstract annotation to define an abstract base class."
 **Expected behavior:**
 - Identifies that `@abstract` is a post-cutoff feature (introduced in Godot 4.5, after LLM knowledge cutoff)
-- Flags the version risk: LLM knowledge of this annotation may be incomplete or incorrect
-- Directs the user to verify against `docs/engine-reference/godot/VERSION.md` and the official 4.5 migration guide
-- Provides best-effort guidance based on the migration notes in the version reference while clearly marking it as unverified
+- Flags the version risk: LLM knowledge of this annotation may be incomplete or incorrect, so the reference docs take precedence
+- Confirms the feature against the version reference before answering — `docs/engine-reference/godot/breaking-changes.md` lists the `@abstract` decorator in its 4.4 → 4.5 table
+- Flags the installed-version gap: `VERSION.md` records `Installed at pin time` as NOT DETERMINED, so the installed editor must be confirmed as 4.5 or later before `@abstract` code will parse
+- Routes the class authoring to godot-gdscript-specialist rather than writing the class itself
 
 ### Case 4: Language selection for a hot path
 **Input:** "The physics query loop runs every frame for 500 objects. Should we use GDScript or C# for this?"
@@ -51,17 +53,17 @@ No gate IDs assigned.
 - Provides a balanced analysis:
   - GDScript: simpler, team familiar, but slower for tight loops
   - C#: faster for CPU-intensive loops, requires .NET runtime, team needs C# knowledge
-- Does NOT make the final decision unilaterally
-- Defers the decision to `lead-programmer` with the analysis as input
+- Does NOT make the final decision unilaterally — presents the trade-off for the user to decide
+- Flags that bringing C#/.NET (or a GDExtension module) into the project is a major tech choice that needs `technical-director` sign-off, not a call it makes alone
 - Notes that GDExtension (C++) is a third option for extreme performance cases and recommends escalating if C# is insufficient
 
 ### Case 5: Context pass — engine version 4.6
 **Input:** Engine version context provided: Godot 4.6, Jolt as default physics. Request: "Set up a RigidBody3D for the player character."
 **Expected behavior:**
-- Reads the 4.6 context and applies the Jolt-default knowledge (from VERSION.md migration notes)
-- Recommends RigidBody3D configuration choices that are Jolt-compatible (e.g., notes any GodotPhysics-specific settings that behave differently under Jolt)
-- References the 4.6 migration note about Jolt becoming default rather than relying on LLM training data alone
-- Flags any RigidBody3D properties that changed behavior between GodotPhysics and Jolt
+- Reads the 4.6 context and the physics module reference (`docs/engine-reference/godot/modules/physics.md`) rather than relying on LLM training data alone
+- States what the reference documents: Jolt is the default 3D engine for new projects, but existing projects keep their setting — so it checks Project Settings → Physics → 3D → Physics Engine before assuming Jolt
+- Carries over the documented Jolt differences that apply: collision margins may behave differently, and Jolt emits runtime warnings for properties it does not support (e.g. HingeJoint3D `damp`)
+- Does NOT invent RigidBody3D property changes between GodotPhysics and Jolt — the reference documents none, and it says so
 
 ---
 
@@ -72,7 +74,8 @@ No gate IDs assigned.
 - [ ] Returns structured findings (decision trees, pattern recommendations with rationale)
 - [ ] Treats `docs/engine-reference/godot/VERSION.md` as authoritative over LLM training data
 - [ ] Flags post-cutoff API usage (4.4, 4.5, 4.6) with verification requirements
-- [ ] Defers language-selection decisions to lead-programmer when trade-offs exist
+- [ ] Leaves language-selection decisions to the user and routes adoption of a new language or runtime to technical-director
+- [ ] Asks "May I write this to [filepath]?" naming the file before writing
 
 ---