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/unity/unity-specialist.md

@@ -3,7 +3,6 @@
 ## Agent Summary
 Domain: Unity-specific architecture patterns, MonoBehaviour vs DOTS decisions, and subsystem selection (Addressables, New Input System, UI Toolkit, Cinemachine, etc.).
 Does NOT own: language-specific deep dives (delegates to unity-dots-specialist, unity-ui-specialist, etc.).
-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 Unity patterns / MonoBehaviour / subsystem 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 acknowledges the sub-specialist routing table (DOTS, UI, Shader, Addressables)
 
 ---
@@ -33,51 +32,54 @@ No gate IDs assigned.
 **Input:** "Set up a Node scene tree with signals for this enemy system."
 **Expected behavior:**
 - Does NOT produce Godot Node/signal code
-- Identifies this as a Godot pattern
-- States that in Unity the equivalent is GameObject hierarchy + UnityEvent or C# events
-- Maps the concepts: Godot Node → Unity MonoBehaviour, Godot Signal → C# event / UnityEvent
-- Confirms the project is Unity-based before proceeding
+- Identifies node trees and signals as Godot concepts
+- Confirms the project's engine from `engine.name` in `project.yaml` rather than guessing; if it is not Unity, says it is the wrong specialist for this project instead of translating
+- If `engine.name` is unset, says no engine is configured and asks which engine the project uses — it does not assume Unity
+- In a Unity project, maps the concepts: node tree → GameObject hierarchy with composed MonoBehaviours; signal → C# event or UnityEvent (consistent with its own rule to use events instead of `SendMessage()` / `Find()`)
+- Does not hand the request to a Godot specialist — its Agent grant covers only the four Unity sub-specialists
 
 ### Case 3: Unity version API flag
 **Input:** "Use the new Unity 6 GPU resident drawer for batch rendering."
 **Expected behavior:**
-- Identifies the Unity 6 feature (GPU Resident Drawer)
-- Flags that this API may not be available in earlier Unity versions
-- Asks for or checks the project's Unity version before providing implementation guidance
-- Directs to verify against official Unity 6 documentation
-- Does NOT assume the project is on Unity 6 without confirmation
+- Checks `docs/engine-reference/unity/VERSION.md` and `docs/engine-reference/unity/modules/rendering.md` before answering, not training data (the version file places Unity 6 past the model's knowledge cutoff)
+- States what the reference documents: GPU Resident Drawer is a Unity 6+ feature enabled in the URP Asset (Rendering > GPU Resident Drawer), so it requires an SRP project
+- Flags the installed-version gap: when `Installed at pin time` in the version file is not determined, asks which editor version is installed before recommending the feature
+- Does NOT assume the installed editor is Unity 6 because the reference is pinned to it
+- Proposes the URP Asset change and asks before editing it; routes render pipeline customization beyond the setting to `unity-shader-specialist`
 
 ### Case 4: DOTS vs. MonoBehaviour conflict
 **Input:** "The combat system uses MonoBehaviour for state management, but we want to add a DOTS-based projectile system. Can they coexist?"
 **Expected behavior:**
 - Recognizes this as a hybrid architecture scenario
-- Explains the hybrid approach: MonoBehaviour can interface with DOTS via SystemAPI, IComponentData, and managed components
+- Explains the coexistence mechanism at architecture level, as `docs/engine-reference/unity/plugins/dots-entities.md` documents it: authoring MonoBehaviours baked into entities by a `Baker<T>`, projectile data held in `IComponentData`, processed by an `ISystem`
 - Notes the performance and complexity trade-offs of mixing the two patterns
 - Recommends escalating the architecture decision to `lead-programmer` or `technical-director`
 - Defers to `unity-dots-specialist` for the DOTS-side implementation details
 
 ### Case 5: Context pass — Unity version
-**Input:** Project context provided: Unity 2023.3 LTS. Request: "Configure the new Input System for this project."
+**Input:** Project context provided: Unity 6.3 LTS, keyboard/mouse and gamepad targets. Request: "Configure the new Input System for this project."
 **Expected behavior:**
-- Applies Unity 2023.3 LTS context: uses the New Input System (com.unity.inputsystem) package
-- Does NOT produce legacy Input Manager code (`Input.GetKeyDown()`, `Input.GetAxis()`)
-- Notes any 2023.3-specific Input System behaviors or package version constraints
-- References the project version to confirm Burst/Jobs compatibility if the Input System interacts with DOTS
+- Applies the Unity 6.3 LTS context from `docs/engine-reference/unity/modules/input.md`: the Input System package (`com.unity.inputsystem`) with Active Input Handling set to the new system
+- Does NOT produce legacy Input Manager code (`Input.GetKeyDown()`, `Input.GetAxis()`) — the engine reference lists these as deprecated
+- Defines actions in an `.inputactions` asset, uses the Player Input component or a generated C# class, and prefers action callbacks (`performed`, `canceled`) over polling in `Update()`
+- Sets up keyboard+mouse and gamepad control schemes with automatic switching
+- Routes UI navigation and input-prompt work to `unity-ui-specialist`
+- Treats adding the package as a dependency decision needing `technical-director` sign-off, and asks before writing any settings or asset
 
 ---
 
 ## Protocol Compliance
 
 - [ ] Stays within declared domain (Unity architecture decisions, pattern selection, subsystem routing)
-- [ ] Redirects Godot patterns to appropriate Godot specialists or flags them as wrong-engine
+- [ ] Treats Godot patterns as wrong-engine: checks `engine.name`, answers with the Unity equivalent, never emits Godot code
 - [ ] Redirects DOTS implementation to unity-dots-specialist
 - [ ] Redirects UI implementation to unity-ui-specialist
-- [ ] Flags Unity version-gated APIs and requires version confirmation before suggesting them
+- [ ] Checks `docs/engine-reference/unity/` (pinned version and `Installed at pin time`) before suggesting a version-gated API, and confirms the installed version when it is not recorded
 - [ ] Returns structured pattern decision guides, not freeform opinions
 
 ---
 
 ## Coverage Notes
 - MonoBehaviour vs. ScriptableObject (Case 1) should be documented as an ADR if it results in a project-level decision
-- Version flag (Case 3) confirms the agent does not assume the latest Unity version without context
+- Version flag (Case 3) confirms the agent checks the pinned and installed Unity version rather than assuming the latest
 - DOTS hybrid (Case 4) verifies the agent escalates architecture conflicts rather than resolving them unilaterally