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-umg-specialist.md

@@ -1,9 +1,8 @@
 # Agent Test Spec: ue-umg-specialist
 
 ## Agent Summary
-- **Domain**: UMG widget hierarchy design, data binding patterns, CommonUI input routing and action tags, widget styling (WidgetStyle assets), UI optimization (widget pooling, ListView, invalidation)
+- **Domain**: UMG widget hierarchy design, data binding patterns, CommonUI input routing and input action data, widget styling (WidgetStyle assets), UI optimization (widget pooling, ListView, invalidation)
 - **Does NOT own**: UX flow and screen navigation design (ux-designer), gameplay logic (gameplay-programmer), backend data sources (game code), server communication
-- **Model tier**: Sonnet
 - **Gate IDs**: None; defers UX flow decisions to ux-designer
 
 ---
@@ -11,8 +10,8 @@
 ## Static Assertions (Structural)
 
 - [ ] `description:` field is present and domain-specific (references UMG, widget hierarchy, CommonUI)
-- [ ] `allowed-tools:` list matches the agent's role (Read/Write for UI assets and Blueprint files; no server or gameplay source tools)
-- [ ] Model tier is Sonnet (default for specialists)
+- [ ] `tools:` reads Read, Glob, Grep, Write, Edit, Bash — no `Agent` tool
+- [ ] Model tier is `sonnet` — frontmatter `model:` reads exactly `sonnet` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition does not claim authority over UX flow, navigation architecture, or gameplay data logic
 
 ---
@@ -23,7 +22,7 @@
 **Input**: "Create an inventory widget that shows a grid of item slots. Each slot should display item icon, quantity, and rarity color. It needs to update when the inventory changes."
 **Expected behavior**:
 - Produces a UMG widget structure: a parent WBP_Inventory containing a UniformGridPanel or TileView, with a child WBP_InventorySlot widget per item
-- Describes data binding approach: either Event Dispatchers on an Inventory Component triggering a refresh, or a ListView with a UObject item data class implementing IUserObjectListEntry
+- Describes data binding approach: either Event Dispatchers on an Inventory Component triggering a refresh, or a TileView fed UObject-based item data (not raw structs); it names the entry widget's list-entry interface (`IUserObjectListEntry`) and marks it unverified against `docs/engine-reference/unreal/`, which does not document it
 - Specifies how rarity color is driven: a WidgetStyle asset or a data table lookup, not hardcoded color values
 - Output includes the widget hierarchy, binding pattern, and the refresh trigger mechanism
 
@@ -31,15 +30,15 @@
 **Input**: "Design the full navigation flow for our inventory system — how the player opens it, transitions to character stats, and exits to the pause menu."
 **Expected behavior**:
 - Does not produce a navigation flow or screen transition architecture
-- States clearly: "Navigation flow and screen transition design is owned by ux-designer; I can implement the UMG widget structure once the flow is defined"
-- Does not make UX decisions (back button behavior, transition animations, modal vs. fullscreen) without a UX spec
+- Names ux-designer, its coordination partner for interaction design, as the owner of the flow, and offers to build the screens on its layered architecture (Menu Layer, `UCommonActivatableWidgetStack`) once the flow is defined
+- Does not make UX decisions (back button behavior, transition animations, modal vs. fullscreen) without a UX spec — it asks for the spec or lists these as open questions instead
 
 ### Case 3: Domain boundary — CommonUI input action mismatch
 **Input**: "Our inventory widget isn't responding to the controller Back button. We're using CommonUI."
 **Expected behavior**:
-- Identifies the likely cause: the widget's Back input action tag does not match the project's registered CommonUI InputAction data asset
-- Explains the CommonUI input routing model: widgets declare input actions via `CommonUI_InputAction` tags; the CommonActivatableWidget handles routing
-- Provides the fix: verify that the widget's Back action tag matches the registered tag in the project's CommonUI input action data table
+- Identifies the likely causes: the widget's Back binding does not point at the Back row of the project's `CommonInputActionDataBase` data table, or the widget is not the activated, focused screen on its stack
+- Explains the CommonUI input routing model: screens derive from `UCommonActivatableWidget` and bind UI actions to data-table rows; only the focused, activated widget consumes input and unfocused widgets ignore it
+- Provides the fix: verify the Back binding's data-table row and that the widget is pushed onto (and active on) its activatable-widget stack
 - Distinguishes this from a hardware input binding issue (which would be Enhanced Input territory)
 
 ### Case 4: Widget performance issue — many widget instances per frame
@@ -47,28 +46,29 @@
 **Expected behavior**:
 - Identifies the root cause: 500 widget instantiations in a single frame causes a construction hitch
 - Recommends switching to ListView or TileView with virtualization — only visible rows are constructed
-- Explains the IUserObjectListEntry interface requirement for ListView data objects
+- Explains the ListView data requirement: each row's data is a UObject-based entry item, not a raw struct; it names the row widget's list-entry interface (`IUserObjectListEntry`) and marks it unverified against `docs/engine-reference/unreal/`
 - If ListView is not appropriate, recommends pooling: pre-instantiate a fixed number of rows and recycle them with new data
 - Output is a concrete recommendation with the specific UMG component to use, not a vague "optimize it"
 
 ### Case 5: Context pass — CommonUI setup already configured
-**Input context**: Project uses CommonUI with the following registered InputAction tags: UI.Action.Confirm, UI.Action.Back, UI.Action.Pause, UI.Action.Secondary.
+**Input context**: Project uses CommonUI; its `CommonInputActionDataBase` data table defines these input action rows: Confirm, Back, Pause, Secondary.
 **Input**: "Add a 'Sort Inventory' button to the inventory widget that works with CommonUI."
 **Expected behavior**:
-- Uses UI.Action.Secondary (or recommends registering a new tag like UI.Action.Sort if Secondary is already allocated)
-- Does NOT invent a new InputAction tag without noting that it must be registered in the CommonUI data table
-- Does NOT use a non-CommonUI input binding approach (e.g., raw key press in Event Graph) when CommonUI is the established pattern
-- References the provided tag list explicitly in the recommendation
+- Uses the existing Secondary row (or recommends adding a new Sort row if Secondary is already allocated on this screen)
+- Does NOT invent a new input action without noting that it must be added as a row to the project's CommonUI input action data table
+- Uses a `UCommonButtonBase` for the button and CommonUI's input routing — not a non-CommonUI binding (e.g., raw key press in Event Graph or `APlayerController::InputComponent`)
+- References the provided action rows explicitly in the recommendation
 
 ---
 
 ## Protocol Compliance
 
 - [ ] Stays within declared domain (UMG structure, data binding, CommonUI, widget performance)
-- [ ] Redirects UX flow and navigation design requests to ux-designer
+- [ ] Redirects UX flow and navigation design requests to ux-designer, making no binding UX decisions itself
 - [ ] Returns structured findings (widget hierarchy + binding pattern) rather than freeform opinions
-- [ ] Uses existing CommonUI InputAction tags from context; does not invent new ones without flagging registration requirement
+- [ ] Uses existing CommonUI input action rows from context; does not invent new ones without flagging that they must be added to the data table
 - [ ] Recommends virtualized lists (ListView/TileView) before widget pooling for large collections
+- [ ] Asks "May I write this to [filepath]?" naming the file before writing
 
 ---