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/unreal/ue-blueprint-specialist.md

@@ -2,17 +2,16 @@
 
 ## Agent Summary
 - **Domain**: Blueprint architecture, the Blueprint/C++ boundary, Blueprint graph quality, Blueprint performance optimization, Blueprint Function Library design
-- **Does NOT own**: C++ implementation (engine-programmer or gameplay-programmer), art assets or shaders, UI/UX flow design (ux-designer)
-- **Model tier**: Sonnet
-- **Gate IDs**: None; defers to unreal-specialist or lead-programmer for cross-domain rulings
+- **Does NOT own**: C++ implementation (gameplay-programmer exposes the C++ hooks Blueprint calls), art assets or shaders, UI/UX flow design (ux-designer)
+- **Gate IDs**: None; defers C++/Blueprint boundary architecture rulings to unreal-specialist
 
 ---
 
 ## Static Assertions (Structural)
 
 - [ ] `description:` field is present and domain-specific (references Blueprint architecture and optimization)
-- [ ] `allowed-tools:` list matches the agent's role (Read for Blueprint project files; no server or deployment tools)
-- [ ] Model tier is Sonnet (default for specialists)
+- [ ] `tools:` list matches the agent's role (Read/Write/Edit for Blueprint-facing files; no server or deployment tools, and Bash withheld via `disallowedTools:`)
+- [ ] Model tier is `sonnet` — frontmatter `model:` reads exactly `sonnet` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition does not claim authority over C++ implementation decisions
 
 ---
@@ -23,26 +22,25 @@
 **Input**: "Review our AI behavior Blueprint. It has tick-based logic running every frame that checks line-of-sight for 30 NPCs simultaneously."
 **Expected behavior**:
 - Identifies tick-heavy logic as a performance problem
-- Recommends switching from EventTick to event-driven patterns (perception system events, timers, or polling on a reduced interval)
-- Flags the per-NPC cost of simultaneous line-of-sight checks
-- Suggests alternatives: AIPerception component events, staggered tick groups, or moving the system to C++ if Blueprint overhead is measured to be significant
-- Output is structured: problem identified, impact estimated, alternatives listed
+- Recommends switching from EventTick to event-driven patterns (perception system events, timers, or polling on a reduced interval) — never polling every frame when an event would suffice
+- Flags the per-NPC cost of simultaneous line-of-sight checks, including any loop over the NPC array inside Tick
+- Recommends profiling first (`stat game`, Blueprint profiler), and treats moving the system to C++ as warranted when the measured Blueprint overhead is significant — 30 NPCs is below its automatic C++ threshold (tick logic with more than 100 instances)
+- Output names, for each finding, the Performance Rule or Review Checklist item it breaks and the replacement pattern
 
 ### Case 2: Out-of-domain request — C++ implementation
 **Input**: "Write the C++ implementation for this ability cooldown system."
 **Expected behavior**:
-- Does not produce C++ implementation code
-- Provides the Blueprint equivalent of the cooldown logic (e.g., using a Timeline or GameplayEffect if GAS is in use)
-- States clearly: "C++ implementation is handled by engine-programmer or gameplay-programmer; I can show the Blueprint approach or describe the boundary where Blueprint calls into C++"
-- Optionally notes when the cooldown complexity warrants a C++ backend
+- Classifies the cooldown system with its boundary rules: ability-system logic is on its "Must Be C++" list, so it does not offer a Blueprint reimplementation of the system
+- Describes the boundary instead: C++ defines the framework and exposes hooks (`BlueprintCallable`, `BlueprintNativeEvent`, `BlueprintImplementableEvent`); Blueprint supplies tuning values (`EditAnywhere` / `BlueprintReadWrite`) and simple event responses such as cooldown feedback
+- Routes the C++ implementation to gameplay-programmer (its named partner for exposing C++ hooks to Blueprint) and the boundary decision to unreal-specialist, rather than writing the C++ system itself
 
 ### Case 3: Domain boundary — unsafe raw pointer access in Blueprint
 **Input**: "Our Blueprint calls GetOwner() and then immediately accesses a component on the result without checking if it's valid."
 **Expected behavior**:
-- Flags this as a runtime crash risk: GetOwner() can return null in some lifecycle states
-- Provides the correct Blueprint pattern: IsValid() node before any property/component access
+- Flags this as a runtime crash risk under its Review Checklist item "Error/failure paths are handled (not just the happy path)": GetOwner() can return null in some lifecycle states
+- Provides the correct Blueprint pattern: IsValid() node before any property/component access, with the invalid branch handled
 - Notes that Blueprint's null checks are not optional on Actor-derived references
-- Does NOT silently fix the code without explaining why the original was unsafe
+- Does NOT silently fix the code — explains why the original was unsafe and asks before editing the Blueprint
 
 ### Case 4: Blueprint graph complexity — readiness for Function Library refactor
 **Input**: "Our main GameMode Blueprint has 600+ nodes in a single graph with duplicated damage calculation logic in 8 places."
@@ -57,24 +55,25 @@
 **Input context**: Project conventions specify a maximum of 100 nodes per Blueprint event graph before a mandatory Function Library extraction.
 **Input**: "Here is our inventory Blueprint graph [150 nodes shown]. Is it ready to ship?"
 **Expected behavior**:
-- References the stated 150-node count against the 100-node budget from project conventions
+- References the stated 150-node count against the 100-node event-graph budget from project conventions
 - Flags the graph as exceeding the complexity threshold
 - Does NOT approve it as-is
 - Produces a list of candidate subgraphs for Function Library extraction to bring the main graph within budget
+- Applies its own standard (maximum 20 nodes per function graph) to the extracted functions, keeping it distinct from the project's event-graph budget rather than substituting one number for the other
 
 ---
 
 ## Protocol Compliance
 
 - [ ] Stays within declared domain (Blueprint architecture, performance, graph quality)
-- [ ] Redirects C++ implementation requests to engine-programmer or gameplay-programmer
-- [ ] Returns structured findings (problem/impact/alternatives format) rather than freeform opinions
+- [ ] Routes C++ implementation requests to gameplay-programmer and boundary rulings to unreal-specialist
+- [ ] Grounds findings in its own Performance Rules and Blueprint Review Checklist, naming the rule each finding breaks, rather than freeform opinions
 - [ ] Enforces Blueprint safety patterns (null checks, IsValid) proactively
-- [ ] References project conventions when evaluating graph complexity
+- [ ] References project conventions when evaluating graph complexity, alongside its own per-function node limit
 
 ---
 
 ## Coverage Notes
 - Case 3 (null pointer safety) is a safety-critical test — this is a common source of shipping crashes
-- Case 5 requires that project conventions include a stated node budget; if none is configured, the agent should note the absence and recommend setting one
+- Case 5 requires that project conventions include a stated node budget; if none is configured, the agent falls back to its own standard (maximum 20 nodes per function graph) and says so
 - No automated runner; review manually or via `/skill-test`