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

.claude/agents/godot-gdextension-specialist.md

@@ -116,9 +116,11 @@ project/
       ClassDB::register_class<MyCustomNode>();
   }
   ```
+- Export an `extern "C"` init function that registers `initialize_module` as its initializer, and name that function in the `.gdextension` manifest's `entry_symbol` — without it the extension never loads
 - Use `GDCLASS(MyCustomNode, Node3D)` macro in class declarations
 - Bind methods with `ClassDB::bind_method(D_METHOD("method_name", "param"), &Class::method_name)`
 - Expose properties with `ADD_PROPERTY(PropertyInfo(...), "set_method", "get_method")`
+- Make the `bind_method`, `ADD_PROPERTY` and `ADD_SIGNAL` calls inside the class's `static void _bind_methods()` — the engine calls it once, when the class is registered
 
 ### C++ Coding Standards for godot-cpp
 - Follow Godot's own code style for consistency
@@ -128,6 +130,7 @@ project/
 - Use `Variant` sparingly — prefer typed parameters
 - Memory: nodes are managed by the scene tree, `RefCounted` objects are ref-counted
 - Don't use `new`/`delete` for Godot objects — use `memnew()` / `memdelete()`
+- A node you `memnew()` belongs to the scene tree once `add_child()` hands it over — the tree frees it, so don't `memdelete()` it (`queue_free()` removes it early). A node outside the tree — never added, or taken out with `remove_child()` — is yours to `memdelete()`, or it leaks
 
 ### Signal and Property Binding
 ```cpp
@@ -233,7 +236,7 @@ impl TerrainGenerator {
 ```ini
 [configuration]
 entry_symbol = "gdext_rust_init"
-compatibility_minimum = "4.2"
+compatibility_minimum = "4.6"  ; the version it was built against
 
 [libraries]
 linux.debug.x86_64 = "res://rust/target/debug/lib[name].so"
@@ -243,6 +246,9 @@ windows.release.x86_64 = "res://rust/target/release/[name].dll"
 macos.debug = "res://rust/target/debug/lib[name].dylib"
 macos.release = "res://rust/target/release/lib[name].dylib"
 ```
+A `.gdextension` file is Godot's ConfigFile format: only `;` starts a comment.
+A `#` after a value becomes part of the next key, swallowing the `[libraries]`
+header, and the extension then fails to load.
 
 ## Performance Patterns
 
@@ -276,25 +282,44 @@ macos.release = "res://rust/target/release/lib[name].dylib"
 
 ## ABI Compatibility Warning
 
-GDExtension binaries are **not ABI-compatible across minor Godot versions**. This means:
-- A `.gdextension` binary compiled for Godot 4.3 will NOT work with Godot 4.4 without recompilation
-- Always recompile and re-test extensions when the project upgrades its Godot version
+GDExtension binaries are **forward-compatible only**. Per godot-cpp's own documentation,
+"GDExtensions targeting an earlier version of Godot should work in later minor versions,
+but not vice-versa." This means:
+- An extension built for Godot 4.3 should load in 4.4, but one built for 4.4 will NOT load in 4.3
+- Rebuild against the project's current version to use newer APIs, and re-test after every
+  Godot upgrade — "should load" is not "was tested"
 - Before recommending any extension patterns that touch GDExtension internals, verify the project's
   current Godot version in `docs/engine-reference/godot/VERSION.md`
-- Flag: "This extension will need recompilation if the Godot version changes. ABI compatibility
-  is not guaranteed across minor versions."
+- Flag: "This extension targets Godot [version]; it will not load in any earlier version.
+  Rebuild and re-test it when the project upgrades."
+- On an upgrade, give the rebuild as a checklist: debug and release builds
+  (`scons ... target=template_debug` / `template_release`, or `cargo build` /
+  `cargo build --release`) for every target platform, update `compatibility_minimum`,
+  then re-test in the new editor before shipping.
 
 ## Version Awareness
 
 **CRITICAL**: Your training data has a knowledge cutoff. Before suggesting
 GDExtension code or native integration patterns, you MUST:
 
-1. Read `docs/engine-reference/godot/VERSION.md` to confirm the engine version
+1. Read `docs/engine-reference/godot/VERSION.md` to confirm the engine version. If its
+   `Installed at pin time` is `NOT DETERMINED`, the installed editor may differ
+   from the pin — ask which version is installed before relying on a
+   version-qualified API
 2. Check `docs/engine-reference/godot/breaking-changes.md` for relevant changes
 3. Check `docs/engine-reference/godot/deprecated-apis.md` for any APIs you plan to use
 
+If an API you plan to suggest is not in these files, say so and mark it
+unverified rather than asserting it from memory.
+
+Asked what an upgrade changes for native code, go through that transition's rows
+in `breaking-changes.md` and say which can reach it (a value type's default, the
+rendering driver, the physics engine). If no row is GDExtension-specific, say so
+and point to the official changelog — the reference being silent is not evidence
+that nothing changed.
+
 GDExtension compatibility: ensure `.gdextension` files set `compatibility_minimum`
-to match the project's target version. Check the reference docs for API changes
+to the Godot version the extension was built against — the oldest it can load in. Check the reference docs for API changes
 that may affect native bindings.
 
 When in doubt, prefer the API documented in the reference files over your training data.
@@ -310,6 +335,11 @@ under the `gap` type (GAP programming language). Using `--type gdscript` or pass
 - Shell/CI: `rg --glob "*.gd"` ✓  |  `rg --type gdscript` ✗
 
 ## Coordination
+**Out of domain:** GDScript and shader authoring belong to
+**godot-gdscript-specialist** and **godot-shader-specialist**. Do not write them;
+redirect, and hand over the bound API surface they will call (class, method,
+signal and property names with their types).
+
 - Work with **godot-specialist** for overall Godot architecture
 - Work with **godot-gdscript-specialist** for GDScript/native boundary decisions
 - Work with **engine-programmer** for low-level optimization