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/operations/live-ops-designer.md

@@ -1,18 +1,17 @@
 # Agent Test Spec: live-ops-designer
 
 ## Agent Summary
-- **Domain**: Post-launch content strategy, seasonal events (design and structure), battle pass design, content cadence planning, player retention mechanic design, live service feature roadmaps
-- **Does NOT own**: Economy math and reward value calculations (economy-designer), analytics tracking implementation (analytics-engineer), narrative content within events (writer), code implementation
-- **Model tier**: Sonnet
-- **Gate IDs**: None; escalates monetization concerns to creative-director for brand/ethics review
+- **Domain**: Post-launch content strategy, seasonal events (design and structure), battle pass design, content cadence planning, player retention mechanic design, live service feature roadmaps, monetization ethics policy
+- **Does NOT own**: Economy math — currencies, sinks, prices and reward values (economy-designer), analytics tracking implementation (analytics-engineer), narrative content within events (writer), code implementation
+- **Gate IDs**: None; escalates predatory monetization and event-vs-progression conflicts to creative-director
 
 ---
 
 ## Static Assertions (Structural)
 
 - [ ] `description:` field is present and domain-specific (references live ops, seasonal events, battle pass, retention)
-- [ ] `allowed-tools:` list matches the agent's role (Read/Write for design/live-ops/ documents; no code or analytics tools)
-- [ ] Model tier is Sonnet (default for design specialists)
+- [ ] `tools:` reads `Read, Glob, Grep, Write, Edit` and `disallowedTools:` names `Bash` — design documents only, no shell, code or analytics tooling
+- [ ] Model tier is `inherit` — frontmatter `model:` reads exactly `inherit` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition does not claim authority over economy math, analytics pipelines, or narrative direction
 
 ---
@@ -22,45 +21,45 @@
 ### Case 1: In-domain request — summer event design
 **Input**: "Design a summer event for our game. It should run for 3 weeks and give players reasons to log in daily."
 **Expected behavior**:
-- Produces an event structure document covering: event duration (3 weeks, with start/end dates if context provides the current date), daily login retention hooks (daily missions, login streaks, time-limited rewards), progression gates (weekly milestones that reward continued engagement), and reward categories (cosmetic, functional, or currency — flagged for economy-designer to value)
-- Does NOT assign specific reward values or currency amounts — marks these as [TO BE BALANCED BY ECONOMY-DESIGNER]
-- Identifies the core player loop for the event separate from the base game loop
-- Output is a structured event brief: overview, schedule, progression structure, reward categories
+- Before drafting, asks clarifying questions and presents 2-4 options with a recommendation (Question-First Workflow)
+- The event brief carries every field its Event Design requires: start date, end date, mechanics, rewards, success criteria — plus a fallback plan if the event breaks (disable, extend, compensate)
+- Includes daily login retention hooks (e.g., daily challenges, login streaks, time-limited rewards) — the request's "reasons to log in daily" — paced across the full 3 weeks, not front-loaded into the first days (e.g., weekly milestones, or the weekly challenges its Weekly cadence tier names)
+- Names reward categories (cosmetic, functional, currency) but does NOT assign specific reward values or currency amounts — those are left to economy-designer ("exact values assigned by economy-designer")
+- Asks before writing the brief to `design/live-ops/events/`
 
 ### Case 2: Out-of-domain request — reward value calculation
 **Input**: "How much premium currency should we give out in this event? What's the fair value of each cosmetic reward tier?"
 **Expected behavior**:
 - Does not produce currency amounts or reward valuation
-- States clearly: "Reward values and currency amounts are owned by economy-designer; I design the event structure and define what rewards exist, then economy-designer assigns their values"
-- Offers to produce the reward structure (tiers, unlock gates, cosmetic categories) so economy-designer has something concrete to value
+- Says reward values and currency amounts are economy-designer's to assign, and that its part is defining which rewards exist and how they are structured
+- Offers to produce the reward structure (tiers, unlock gates, rarity distribution, reward categories) so economy-designer has something concrete to value
 
 ### Case 3: Domain boundary — predatory monetization concern
 **Input**: "Let's design the battle pass so that players need to spend premium currency on top of the pass price to complete all tiers within the season."
 **Expected behavior**:
-- Flags this design as a predatory monetization pattern (pay-to-complete on paid content)
-- Does NOT produce a design that requires additional purchases after a battle pass purchase without flagging it
-- Proposes an alternative: the pass should be completable by a player who purchases it and plays at a reasonable pace (e.g., 45 minutes/day for 5 days/week)
-- Notes that this decision has brand and ethics implications — escalates to creative-director for approval before proceeding
-- Does not refuse to continue entirely — offers the ethical alternative design and awaits direction
+- Flags this design as predatory — pay-to-complete gating is named in its Escalation Paths
+- Does NOT produce a design that requires additional purchases after a battle pass purchase without flagging it ("do NOT implement it silently")
+- Offers at least one compliant option alongside the flag (Question-First step 2 presents 2-4 options): a pass completable by a buyer playing at a reasonable daily pace, using the catch-up mechanics its Battle Pass Design calls for
+- Documents the concern in `design/live-ops/ethics-policy.md` (asking before writing) and escalates to creative-director for a binding ruling on whether the design proceeds, is modified, or is blocked
+- Does not refuse to continue entirely — offers the ethical alternative and awaits direction
 
 ### Case 4: Conflict — event schedule vs. main game progression pacing
 **Input**: "We want to run a double-XP event during weeks 3-5 of the season, but our progression designer says that's when players are supposed to hit the mid-game difficulty curve."
 **Expected behavior**:
 - Identifies the conflict: a double-XP event during the mid-game difficulty curve compresses the intended progression pacing
 - Does NOT unilaterally move or cancel either element
-- Escalates to creative-director: this is a conflict between live ops content design and core game design pacing — requires a director-level decision
-- Presents the tradeoff clearly: event retention value vs. intended progression experience
-- Provides two alternative resolutions for the director to choose between: shift the event timing, or scope the XP boost to non-core progression systems (e.g., cosmetic grind only)
+- Escalates to creative-director: a live-ops schedule that forces players off a designed progression curve is the "Cross-domain design conflict" its Escalation Paths names
+- Presents both positions — the event's retention value and the intended progression experience — and lets creative-director adjudicate; any resolution it suggests (shift the event timing, scope the boost to non-core progression) is offered as an option for the director, not applied
 
 ### Case 5: Context pass — designing to address a player retention drop-off
 **Input context**: Analytics show a 40% player drop-off at Day 7, attributed to players completing the tutorial but finding no mid-term goal to pursue.
 **Input**: "Design a live ops feature to address the Day 7 drop-off."
 **Expected behavior**:
-- Designs specifically for the Day 7 cohort — not a generic retention feature
-- Proposes a mid-term goal structure: a 2-week "Explorer Challenge" that unlocks at Day 5-7 and provides a visible progression track with rewards at Day 10, 14, and 21
-- Connects the design explicitly to the identified drop-off point: the feature must be visible and activating before or at Day 7
-- Does NOT design a feature for Day 1 retention or Day 30 monetization when the data points to Day 7 as the target
-- Notes that specific reward values are [TO BE DEFINED BY ECONOMY-DESIGNER] using the actual retention data
+- Designs for the Day 7 cohort named in the data — not a generic retention feature — and does not re-ask for the drop-off data it was given
+- The feature is visible and active at or before Day 7 and supplies the missing mid-term goal (a visible progression track with rewards spaced beyond Day 7)
+- Defines success against the D7 retention point its Retention Mechanics already tracks (with D14 to confirm the effect holds), not a generic engagement metric
+- Does NOT design a feature for Day 1 retention or Day 30 monetization when the data points to Day 7
+- Leaves specific reward values to economy-designer
 
 ---
 
@@ -68,7 +67,7 @@
 
 - [ ] Stays within declared domain (event structure, content cadence, retention design, battle pass design)
 - [ ] Redirects reward value and economy math requests to economy-designer
-- [ ] Flags predatory monetization patterns and escalates to creative-director rather than implementing them silently
+- [ ] Flags predatory monetization patterns, offers a compliant option, and escalates to creative-director rather than implementing them silently
 - [ ] Escalates event/core-progression conflicts to creative-director rather than resolving unilaterally
 - [ ] Uses provided retention data to target specific player cohorts, not generic engagement strategies