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/leads/systems-designer.md

@@ -1,10 +1,9 @@
 # Agent Test Spec: systems-designer
 
 ## Agent Summary
-**Domain owned:** Combat formulas, progression curves, crafting recipes, status effect interactions, economy math, numerical balance.
-**Does NOT own:** Narrative and lore (narrative-director), visual design (art-director), code implementation (lead-programmer), conceptual mechanic rules (game-designer — collaborates with).
-**Model tier:** Sonnet (individual system analysis — formula review and balance math).
-**Gate IDs handled:** Systems review verdicts on formulas and balance specs (uses APPROVED / NEEDS REVISION vocabulary).
+**Domain owned:** Combat formulas, progression curves, crafting recipes, status effect interaction matrices, feedback loop analysis, tuning documentation, simulation specs.
+**Does NOT own:** High-level design direction (game-designer — direct collaboration partner), level and encounter design (level-designer), narrative and aesthetic decisions, code implementation.
+**Gate IDs handled:** None. Formula reviews return findings and options; design-review verdicts come from the `/design-review` skill, which spawns systems-designer as a specialist.
 
 ---
 
@@ -13,8 +12,8 @@
 Verified by reading the agent's `.claude/agents/systems-designer.md` frontmatter:
 
 - [ ] `description:` field is present and domain-specific (references formulas, progression curves, balance math, economy — not generic)
-- [ ] `allowed-tools:` list is read-focused; may include Bash for formula evaluation scripts if the project uses them; no write access outside `design/balance/` without delegation
-- [ ] Model tier is `claude-sonnet-5` per coordination-rules.md
+- [ ] `tools:` list is read/write-focused with Bash excluded (`disallowedTools:` lists Bash); every Write/Edit is gated by its "May I write" step or the orchestrator named-path exception
+- [ ] Model tier is `inherit` — frontmatter `model:` reads exactly `inherit` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition does not claim authority over narrative, visual design, or conceptual mechanic rule ownership
 
 ---
@@ -22,30 +21,30 @@ Verified by reading the agent's `.claude/agents/systems-designer.md` frontmatter
 ## Test Cases
 
 ### Case 1: In-domain request — appropriate output format
-**Scenario:** A damage formula is submitted for review: `damage = base_attack * (1 + strength_modifier * 0.1) - defense * 0.5`, with defined ranges: base_attack [10–100], strength_modifier [0–20], defense [0–50]. The formula produces positive damage across all valid input ranges, scales smoothly, and has no division-by-zero or overflow risk within the defined value bounds.
-**Expected:** Returns `APPROVED` with rationale confirming the formula is balanced within the design parameters, produces valid output across the full input range, and has no degenerate cases.
+**Scenario:** The user asks systems-designer to formalize the combat GDD's damage formula for its Formulas section: `damage = base_attack * (1 + strength_modifier * 0.1) - defense * 0.5`, with ranges base_attack [10–100], strength_modifier [0–20], defense [0–50].
+**Expected:** Produces the formula in the mandatory Formula Output Format. The output range is not safe as written: it spans −15 (base_attack 10, strength_modifier 0, defense 50) to 300 (base_attack 100, strength_modifier 20, defense 0), so the agent flags the negative floor and offers clamping options for the user to choose.
 **Assertions:**
-- [ ] Verdict is exactly one of APPROVED / NEEDS REVISION
-- [ ] Rationale demonstrates verification across the input range (min/max cases checked)
-- [ ] Output stays within systems domain — does not comment on whether the mechanic is fun or how to implement it
-- [ ] Verdict is clearly labeled with context (e.g., "Formula Review: APPROVED")
+- [ ] Output contains all four mandatory parts: named expression, variable table (Symbol / Type / Range / Description, including a result row), output range, and worked example
+- [ ] Output range states the unclamped result spans −15 to 300, identifying the input combination that goes negative
+- [ ] Offers ways to bound the negative floor (e.g., a minimum-damage clamp) as options with a recommendation, leaving the choice to the user
+- [ ] Stays within the systems domain — does not comment on whether the mechanic is fun or how to implement it in code
 
 ### Case 2: Out-of-domain request — redirects or escalates
 **Scenario:** A writer asks systems-designer to draft the quest script for a side quest that rewards the player with a rare crafting ingredient.
-**Expected:** Agent declines to write quest script content and redirects to writer or narrative-director.
+**Expected:** Agent declines to write the quest script — narrative decisions are outside its role — and offers only the systems side of the request: how rare the ingredient reward should be within the crafting economy.
 **Assertions:**
 - [ ] Does not write quest narrative content or dialogue
-- [ ] Explicitly names `writer` or `narrative-director` as the correct handler
-- [ ] May note the systems implications of the reward (e.g., "this ingredient should be rare enough to matter per the crafting economy model"), but defers all script writing to the narrative team
+- [ ] States that the script is narrative work outside its role, leaving it with the writer who asked
+- [ ] Offers the systems contribution instead (e.g., the ingredient's reward rarity or drop rate relative to the crafting economy), without making narrative decisions
 
-### Case 3: Gate verdict — correct vocabulary
-**Scenario:** A damage scaling formula is submitted: `damage = base_attack * level_multiplier`, where `level_multiplier = (player_level / enemy_level) ^ 2`. At max player level (50) against a min-level enemy (1), the multiplier is 2500x — producing 25,000+ damage from a 10-base-attack weapon, far exceeding any meaningful balance. This is a degenerate case at max level.
-**Expected:** Returns `NEEDS REVISION` with specific identification of the degenerate case: at max level vs. min enemy, the formula produces a 2500x multiplier that destroys any balance ceiling.
+### Case 3: Review findings — degenerate case at the boundaries
+**Scenario:** `/design-review` in full mode spawns systems-designer as the adversarial specialist for a combat GDD. The spawn prompt reads: "For every formula in the GDD, plug in boundary values (minimum and maximum plausible inputs). Report whether any outputs go degenerate." The GDD's formula is `damage = base_attack * level_multiplier`, where `level_multiplier = (player_level / enemy_level) ^ 2` and levels run 1–50. At player level 50 against an enemy of level 1, the multiplier is 2500x — 25,000 damage from a 10-base-attack weapon.
+**Expected:** Reports the degenerate case with its exact inputs and output, names the squared ratio as the cause, and offers revision approaches without mandating one. It returns findings, not a verdict — `/design-review` issues the verdict.
 **Assertions:**
-- [ ] Verdict is exactly one of APPROVED / NEEDS REVISION — not freeform text
-- [ ] Rationale includes the specific degenerate input values (player level 50, enemy level 1) and the resulting output (2500x multiplier)
-- [ ] Identifies the specific formula component causing the issue (the squared ratio)
-- [ ] Suggests at least one revision approach (e.g., clamping the ratio, using a log scale) without mandating a choice
+- [ ] Reports the specific degenerate input values (player level 50, enemy level 1) and the resulting output (2500x multiplier, 25,000 damage from 10 base attack)
+- [ ] Identifies the squared level ratio as the component causing the issue, and states the output is unclamped — bounded only by the 1–50 level range, which caps the multiplier at 2500x — rather than calling it unbounded
+- [ ] Suggests at least one revision approach (e.g., clamping the ratio, a log scale) as options, without mandating a choice
+- [ ] Returns findings to the review, not its own APPROVED / NEEDS REVISION stamp
 
 ### Case 4: Conflict escalation — correct parent
 **Scenario:** game-designer wants a simple, 2-variable damage formula for player intuitiveness. systems-designer argues that a 6-variable formula with elemental interactions is necessary for the depth of the combat system. Neither can agree on the right level of complexity.
@@ -57,28 +56,30 @@ Verified by reading the agent's `.claude/agents/systems-designer.md` frontmatter
 - [ ] Remains available to implement whichever complexity level is approved
 
 ### Case 5: Context pass — uses provided context
-**Scenario:** Agent receives a gate context block that includes current balance data: enemy HP values range from 100 to 10,000; player attack values range from 15 to 150; target time-to-kill is 8–12 seconds at balanced matchups; the current formula is under review. A proposed revised formula is submitted.
-**Expected:** Assessment runs the proposed formula against the provided balance data (minimum and maximum input pairs, balanced matchup scenario) and verifies the time-to-kill falls within the 8–12 second target window. References specific numbers from the provided data.
+**Scenario:** The request includes current balance data: enemy HP ranges from 100 to 10,000; player attack ranges from 15 to 150; the balanced matchup is an enemy with 1,000 HP against a player with 100 attack, attacking once per second; target time-to-kill is 8–12 seconds at the balanced matchup. A revised formula is proposed: `damage_per_hit = attack * 0.8`.
+**Expected:** Runs the proposed formula against the provided data. At the balanced matchup, damage per hit is 80, so time-to-kill is 1,000 / 80 = 12.5 seconds — half a second outside the 8–12 second window. The agent reports the miss and offers adjustments as options, using the provided numbers throughout.
 **Assertions:**
-- [ ] Uses the specific HP and attack value ranges from the provided balance data
-- [ ] Calculates or estimates time-to-kill for at minimum a balanced matchup scenario
-- [ ] Verifies the result against the provided 8–12 second target window
-- [ ] Does not give generic balance advice — all assertions use the provided numbers
+- [ ] Uses the provided HP and attack ranges (100–10,000 HP; 15–150 attack) in its variable ranges or analysis
+- [ ] Calculates time-to-kill for the balanced matchup: 1,000 / (100 × 0.8) = 12.5 seconds
+- [ ] Compares the result to the provided 8–12 second window and flags that it misses the upper bound
+- [ ] Does not give generic balance advice — its claims and suggested adjustments use the provided numbers
 
 ---
 
 ## Protocol Compliance
 
-- [ ] Returns verdicts using APPROVED / NEEDS REVISION vocabulary only
+- [ ] Every formula it produces carries the four mandatory parts: named expression, variable table, output range, worked example
 - [ ] Stays within declared systems and formula domain
 - [ ] Escalates player-experience complexity trade-offs to creative-director
-- [ ] Does not make binding narrative, visual, code implementation, or conceptual mechanic decisions
+- [ ] Does not make binding narrative, visual, code-implementation, or conceptual-mechanic decisions
 - [ ] Provides concrete formula analysis, not subjective design opinions
+- [ ] Asks "May I create [filepath] with the section skeleton?" before creating a document, and "May I write this section to [filepath]?" before writing each section
 
 ---
 
 ## Coverage Notes
-- Progression curve review (XP curves, level-up scaling) is not covered — a dedicated case should be added.
+- Progression curve design (XP curves, level-up scaling) is not covered — a dedicated case should be added.
 - Economy model review (resource generation and sink rates, inflation prevention) is not covered.
 - Status effect interaction matrix (stacking rules, priority, immunity interactions) is not covered.
+- Registry awareness (checking `design/registry/entities.yaml` before defining a cross-system value) is not covered.
 - Cross-system formula dependency review (e.g., crafting formula that feeds into combat formula) is not covered — deferred to integration tests.