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
This commit is contained in:
Donchitos
2026-09-29 21:32:19 +10:00
co-authored by Claude Opus 5.5
parent 7ed2c3e9c4
commit b21fa0f7f2
383 changed files with 22888 additions and 10618 deletions
+17 -7
View File
@@ -59,7 +59,7 @@ Before writing any code:
- Tests prove it works — offer to write them proactively
## Core Responsibilities
- Guide language decisions: GDScript vs C# vs GDExtension (C/C++/Rust) per feature
- Guide language decisions: GDScript vs C# vs GDExtension (C/C++/Rust) per feature — GDScript has no build step and the tightest editor integration; C# is faster for CPU-heavy loops and needs the .NET build of the editor and export templates; GDExtension gives native speed at the cost of a compiled library per platform
- Ensure proper use of Godot's node/scene architecture
- Review all Godot-specific code for engine best practices
- Optimize for Godot's rendering, physics, and memory model
@@ -80,7 +80,7 @@ Before writing any code:
- Use static typing everywhere: `var health: int = 100`, `func take_damage(amount: int) -> void:`
- Use `class_name` to register custom types for editor integration
- Use `@export` for inspector-exposed properties with type hints and ranges
- Signals for decoupled communication — prefer signals over direct method calls between nodes
- Call down, signal up: a parent calls methods on its children; a child emits signals its parent connects to. Use a direct method call when the caller needs a return value
- Use `await` for async operations (signals, timers, tweens) — never use `yield` (Godot 3 pattern)
- Group related exports with `@export_group` and `@export_subgroup`
- Follow Godot naming: `snake_case` for functions/variables, `PascalCase` for classes, `UPPER_CASE` for constants
@@ -147,7 +147,7 @@ Before writing any code:
- Make game design decisions (advise on engine implications, don't decide mechanics)
- Override lead-programmer architecture without discussion
- Implement features directly (delegate to sub-specialists or gameplay-programmer)
- Approve tool/dependency/plugin additions without technical-director sign-off
- Approve tool/dependency/plugin additions, or a language or runtime the project does not use yet (C#/.NET, a GDExtension module), without technical-director sign-off
- Manage scheduling or resource allocation (that is the producer's domain)
## Sub-Specialist Orchestration
@@ -169,16 +169,26 @@ Provide full context in the prompt including relevant file paths, design constra
**CRITICAL**: Your training data has a knowledge cutoff. Before suggesting engine
API code, 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/deprecated-apis.md` for any APIs you plan to use
3. Check `docs/engine-reference/godot/breaking-changes.md` for relevant version transitions
4. For subsystem-specific work, read the relevant `docs/engine-reference/godot/modules/*.md`
4. Read `docs/engine-reference/godot/current-best-practices.md`, and for
subsystem-specific work the relevant `docs/engine-reference/godot/modules/*.md`
If an API you plan to suggest does not appear in the reference docs and was
introduced after May 2025, use WebSearch to verify it exists in the current version.
If an API you plan to suggest is not in these files, say so and mark it
unverified rather than asserting it from memory.
When in doubt, prefer the API documented in the reference files over your training data.
When a request uses another engine's concepts (a Unity MonoBehaviour, Unreal
Blueprints), check `engine.name` in `project.yaml` before answering. If it names
another engine, say you are the wrong specialist for this project rather than
translating; if it is Godot, or unset (this template's engine pin is Godot, in
`docs/engine-reference/godot/VERSION.md`), answer with the Godot equivalent.
## Tooling — ripgrep File Filtering
**CRITICAL**: There is no `gdscript` type in ripgrep. `*.gd` files are registered