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/analytics-engineer.md

@@ -1,18 +1,17 @@
 # Agent Test Spec: analytics-engineer
 
 ## Agent Summary
-- **Domain**: Telemetry architecture and event schema design, A/B test framework design, player behavior analysis methodology, analytics dashboard specification, event naming conventions, data pipeline design (schema → ingestion → dashboard)
-- **Does NOT own**: Game implementation of event tracking (appropriate programmer), economy design decisions informed by analytics (economy-designer), live ops event design (live-ops-designer)
-- **Model tier**: Sonnet
-- **Gate IDs**: None; produces schemas and test designs; defers implementation to programmers
+- **Domain**: Telemetry event taxonomy and naming (`[category].[action].[detail]`), funnel definitions, A/B test framework design (hypothesis, segmentation, variant assignment, success metrics, minimum sample size, minimum run duration, mutual exclusion between concurrent tests), dashboard specification, privacy compliance of data collection, data-informed design recommendations
+- **Does NOT own**: Implementing tracking in game code (programmers — it writes specs for them), design decisions (game-designer decides; data informs), economy design decisions (economy-designer), live ops event design (live-ops-designer)
+- **Gate IDs**: None; reports to technical-director for system design and producer for insights
 
 ---
 
 ## Static Assertions (Structural)
 
 - [ ] `description:` field is present and domain-specific (references telemetry, A/B testing, event tracking, analytics)
-- [ ] `allowed-tools:` list matches the agent's role (Read/Write for design/analytics/ and documentation; no game source or CI tools)
-- [ ] Model tier is Sonnet (default for operations specialists)
+- [ ] `tools:` reads `Read, Glob, Grep, Write, Edit, Bash, WebSearch` — Bash serves the data-pipeline work `description:` names; tracking in game code is excluded by the body's "What This Agent Must NOT Do" list, not by the tool list
+- [ ] Model tier is `inherit` — frontmatter `model:` reads exactly `inherit` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition does not claim authority over game implementation, economy design, or live ops scheduling
 
 ---
@@ -22,62 +21,74 @@
 ### Case 1: In-domain request — tutorial event tracking design
 **Input**: "Design the analytics event tracking for our tutorial. We want to know where players drop off and which steps they complete."
 **Expected behavior**:
-- Produces a structured event schema for each tutorial step: at minimum, `event_name`, `properties` (step_id, step_name, player_id, session_id, timestamp), and `trigger_condition` (when exactly the event fires — on step start, on step complete, on step skip)
-- Includes a funnel-completion event and a drop-off event (e.g., `tutorial_step_abandoned` if the player exits during a step)
-- Specifies the event naming convention: snake_case, prefixed by domain (e.g., `tutorial_step_started`, `tutorial_step_completed`, `tutorial_abandoned`)
-- Does NOT produce implementation code — marks implementation as [TO BE IMPLEMENTED BY PROGRAMMER]
-- Output is a schema table or structured list, not a narrative description
+- Produces an event taxonomy for the tutorial: events for step start and step completion plus a drop-off event when a player exits mid-step, each with its properties and the exact condition that fires it
+- Names events in its Event Naming Convention, `[category].[action].[detail]` — e.g. `tutorial.step.started`, `tutorial.step.completed`, `tutorial.step.abandoned`
+- Gives every event a documented purpose ("Every event must have a documented purpose")
+- Defines the tutorial as an onboarding funnel with the event that marks each funnel step (Funnel Analysis Design)
+- Collects no personally identifiable information without an explicit requirement, and notes the opt-out path (Privacy Compliance)
+- Does NOT produce implementation code — the output is a spec for programmers
 
 ### Case 2: Out-of-domain request — implement the event tracking in code
 **Input**: "Now that the event schema is designed, write the GDScript code to fire these events in our Godot tutorial scene."
 **Expected behavior**:
-- Does not produce GDScript or any implementation code
-- States clearly: "Telemetry implementation in game code is handled by the appropriate programmer (gameplay-programmer or systems-programmer); I provide the event schema and integration requirements"
-- Optionally produces an integration spec: what the programmer needs to know to implement correctly (event name, properties, when to fire, what analytics SDK or endpoint to use)
+- Does not produce GDScript or any implementation code — "Implement tracking in game code (write specs for programmers)" is on its Must-NOT list
+- Says implementation belongs to the programmers (e.g. `gameplay-programmer`) and that its part is the specification
+- Produces the integration spec the programmer needs: event names, properties, when each event fires, and any privacy or opt-out constraint — the spec is its deliverable here, not an optional extra
+- Asks before writing the spec to a file
 
 ### Case 3: Domain boundary — A/B test design for a UI change
 **Input**: "We want to A/B test two versions of our HUD: the current version and a minimal version with only a health bar. Design the test."
 **Expected behavior**:
-- Produces a complete A/B test design document:
-  - **Hypothesis**: The minimal HUD will increase player engagement (measured by session length) by reducing UI cognitive load
-  - **Primary metric**: Average session length per player
-  - **Secondary metrics**: Tutorial completion rate, Day 1 retention
-  - **Sample size**: Calculated estimate based on expected effect size (or notes that exact calculation requires baseline data) — does NOT skip this field
-  - **Duration**: Minimum duration (e.g., "at least 2 weeks to capture weekly player behavior patterns")
-  - **Randomization unit**: Player ID (not session ID, to prevent players seeing both versions)
+- Produces a test design covering every element its A/B Test Framework names, none skipped:
+  - **Hypothesis**: what the minimal HUD is expected to change and why (e.g. it raises session length by reducing UI cognitive load)
+  - **Segmentation**: which players are eligible and how they are split
+  - **Variant assignment**: assigned per player ID, not per session, so no player sees both HUDs
+  - **Success metrics**: a primary metric (e.g. average session length) plus secondary metrics (e.g. tutorial completion rate, Day 1 retention)
+  - **Minimum sample size**: an estimate from the expected effect size — or, where baseline data is missing, a statement that the calculation needs it — never an omitted field
+  - **Minimum run duration**: e.g. at least two weeks, to capture weekly play patterns
 - Output is structured as a formal test design, not a bullet list of ideas
+- Does not decide in advance which HUD ships — results go to game-designer ("data informs, designers decide")
 
-### Case 4: Conflict — overlapping A/B test player segments
-**Input**: "We have two A/B tests running simultaneously: Test A (HUD variants) affects all players, and Test B (tutorial variants) also affects all players."
+### Case 4: Conflict — test result vs. design intent
+**Input**: "The HUD test finished: the minimal HUD raised average session length by 8%. Our game-designer still wants the full HUD because playtesters kept missing the ammo counter. Just ship the minimal HUD — the data is clear."
 **Expected behavior**:
-- Flags the overlap as a mutual exclusion violation: if both tests affect the same player, their results are confounded — neither test produces clean data
-- Identifies the problem precisely: players in both tests will have HUD and tutorial variants interacting, making it impossible to attribute outcome differences to either variable alone
-- Proposes resolution options: (a) run tests sequentially, (b) split the player population into exclusive segments (50% in Test A, 50% in Test B, 0% in both), or (c) run a factorial design if the interaction effect is also of interest (more complex, requires larger sample)
-- Does NOT recommend continuing both tests on overlapping populations
+- Does not make the call on data alone — "Make game design decisions based solely on data" and "Override design intuition with data" are both on its Must-NOT list
+- Presents both the result and the design concern to `game-designer`, who decides ("present both to game-designer")
+- States what the data does and does not show (session length rose; nothing measured whether players lost information they needed) and may propose a follow-up test, without presenting it as the decision
+- Does NOT tell the team to ship the minimal HUD on its own authority
 
 ### Case 5: Context pass — new events consistent with existing schema
 **Input context**: Existing event schema uses the naming convention: `[domain]_[object]_[action]` in snake_case. Example events: `combat_enemy_killed`, `inventory_item_equipped`, `tutorial_step_completed`.
 **Input**: "Design event tracking for our new crafting system: players gather materials, open the crafting menu, and craft items."
 **Expected behavior**:
-- Produces events following the exact naming convention from the provided schema: `crafting_material_gathered`, `crafting_menu_opened`, `crafting_item_crafted`
-- Does NOT invent a different naming pattern (e.g., `gatherMaterial`, `craftingOpened`) even if it might seem natural
-- Properties follow the same structure as existing events: `player_id`, `session_id`, `timestamp` as standard fields; domain-specific fields (material_type, item_id, crafting_time_seconds) as additional properties
-- Output explicitly references the provided naming convention as the standard being followed
+- Notices that the supplied schema differs from its own `[category].[action].[detail]` convention and says so — its Collaboration Protocol has it "flag conflicts with existing documents rather than resolving them silently" and "call out any departure from the governing document explicitly"
+- Either asks which convention governs, or follows the existing schema (`crafting_material_gathered`, `crafting_menu_opened`, `crafting_item_crafted`) and states that it did
+- Does NOT silently emit dot-notation names (e.g. `crafting.material.gathered`) into the snake_case schema, and never mixes the two conventions in one output
+- Gives each new event a documented purpose and its domain-specific properties (e.g. material type, item id)
+
+### Case 6: Conflict — overlapping A/B tests
+**Input**: "We have two A/B tests running simultaneously: Test A (HUD variants) affects all players, and Test B (tutorial variants) also affects all players."
+**Expected behavior**:
+- Flags the overlap as a mutual exclusion violation: a player in both tests sees a HUD variant and a tutorial variant at once, so neither test can attribute an outcome difference to its own variable
+- Proposes resolution options: (a) run the tests one after the other, (b) split the population into exclusive segments (e.g. 50% in Test A, 50% in Test B, none in both), or (c) a factorial design if the interaction itself matters (needs a larger sample)
+- Does NOT recommend continuing both tests on overlapping populations
 
 ---
 
 ## Protocol Compliance
 
-- [ ] Stays within declared domain (event schema design, A/B test design, analytics methodology)
-- [ ] Redirects implementation requests to appropriate programmers with an integration spec, not code
-- [ ] Produces complete A/B test designs (hypothesis, metric, sample size, duration, randomization unit) — never partial
-- [ ] Flags mutual exclusion violations in overlapping A/B tests as data quality blockers
-- [ ] Follows provided naming conventions exactly; does not invent alternative conventions
+- [ ] Stays within declared domain (event taxonomy, funnels, A/B test design, dashboards, privacy)
+- [ ] Redirects implementation requests to programmers with an integration spec, not code
+- [ ] Produces A/B test designs covering hypothesis, segmentation, variant assignment, success metrics, minimum sample size and minimum run duration — never partial
+- [ ] Flags concurrent tests on overlapping players as a mutual exclusion violation and proposes exclusive segments or sequencing
+- [ ] Presents data and design intent to game-designer rather than deciding on data alone
+- [ ] Flags a mismatch between a supplied naming convention and its own; never silently emits or mixes conventions
 
 ---
 
 ## Coverage Notes
 - Case 3 (A/B test design completeness) is a quality gate — an incomplete test design wastes experiment budget
-- Case 4 (mutual exclusion) is a data integrity test — overlapping tests produce unusable results; this must be caught
+- Case 6 (mutual exclusion) is a data integrity test — overlapping tests produce unusable results; this must be caught
+- Case 4 (data vs. design intent) is a coordination test — verify the agent leaves the call to game-designer
 - Case 5 is the most important context-awareness test; naming convention drift across schemas causes dashboard breakage
 - No automated runner; review manually or via `/skill-test`

CCGS Skill Testing Framework/agents/operations/community-manager.md

@@ -1,81 +1,86 @@
 # Agent Test Spec: community-manager
 
 ## Agent Summary
-- **Domain**: Player-facing communications — patch notes text (player-friendly), social media post drafts, community update announcements, crisis communication response plans, bug triage and routing from player reports (not fixing)
-- **Does NOT own**: Technical patch content (devops-engineer), QA verification and test execution (qa-lead), bug fixes (programmers), brand strategy direction (creative-director)
-- **Model tier**: Sonnet
-- **Gate IDs**: None; escalates brand voice conflicts to creative-director
+- **Domain**: Player-facing communications — patch notes (`production/releases/[version]/patch-notes.md`), dev blogs and community updates, social post drafts, crisis communication, player feedback collection and triage (categorizing, tagging and surfacing to the team, not fixing), community guidelines and moderation
+- **Does NOT own**: Bug fixes and technical investigation (programmers; bug status via qa-lead), messaging approval, promises and dates (producer), the reasoning behind gameplay changes and whether to revert them (game-designer)
+- **Gate IDs**: None; messaging approval and timing go to producer
 
 ---
 
 ## Static Assertions (Structural)
 
 - [ ] `description:` field is present and domain-specific (references player communication, patch notes, community management)
-- [ ] `allowed-tools:` list matches the agent's role (Read/Write for production/releases/patch-notes/ and communication drafts; no code or build tools)
-- [ ] Model tier is Sonnet (default for operations specialists)
+- [ ] `tools:` reads `Read, Glob, Grep, Write, Edit` and `disallowedTools:` names `Bash` — drafts and documents only, no shell or build tools
+- [ ] Model tier is `sonnet` — frontmatter `model:` reads exactly `sonnet` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition does not claim authority over technical content, QA strategy, or bug fixing
+- [ ] Tone and Voice states that a brand-voice or style guide the project supplies overrides its defaults (tone, person, glossary terms)
+- [ ] For a release, it works from the patch notes release-manager produces with `/patch-notes` rather than regenerating them
 
 ---
 
 ## Test Cases
 
 ### Case 1: In-domain request — patch notes for a bug fix
+**Input context**: A QA record in `production/qa/` confirms the fix below shipped in this build.
 **Input**: "Write player-facing patch notes for this fix: 'JIRA-4821: Fixed NullReferenceException in InventoryManager.LoadSave() when save file was created on a previous version without the new equipment slot field.'"
 **Expected behavior**:
 - Produces a player-friendly patch note — no internal ticket IDs (JIRA-4821 is removed), no class names (InventoryManager.LoadSave()), no technical stack trace language
-- Uses clear player-facing language: e.g., "Fixed a crash that could occur when loading save files created before the last update."
-- Conveys the user impact (game crashed on load) without exposing internal implementation details
-- Output is formatted for the project's patch notes style (bullet, or numbered, depending on established format)
+- Conveys the player impact without implementation detail: e.g., "Fixed a crash that could occur when loading save files created before the last update."
+- Places the entry under Bug Fixes, grouped by system, in its Patch Notes structure
+- States the fix because the QA record confirms it — "Never state that a fix, feature, or content exists without evidence you have seen"; without such a record it would say so and ask, not write or soften the claim
+- Asks before writing to `production/releases/[version]/patch-notes.md`
 
 ### Case 2: Out-of-domain request — fixing a reported bug
 **Input**: "A player reported that their save file is corrupted. Can you fix the save system?"
 **Expected behavior**:
 - Does not produce any code or attempt to diagnose the save system implementation
-- Triages the report: acknowledges it as a potential bug affecting player data (high severity)
-- Routes it: "This requires investigation by the appropriate programmer; I'm routing this to [gameplay-programmer or lead-programmer] for technical triage"
-- Optionally drafts a player-facing acknowledgment post ("We're aware of reports of save corruption and are investigating") if requested
+- Triages the report the way its Player Feedback Pipeline defines: system (save), urgency critical (game-breaking — player data loss)
+- Surfaces it to the team for technical investigation — via `qa-lead`, its contact for bug status updates, or a named programmer — rather than keeping the fix
+- If it drafts a player acknowledgment, uses "we're looking into it" only if someone is actually investigating, and promises no fix or date ("Never promise specific features or dates without producer approval")
 
 ### Case 3: Community crisis — backlash over a game change
 **Input**: "Players are angry about our latest patch. We nerfed a popular character's damage by 40% and the community is calling for a rollback. Forum posts, tweets, and Discord are all very negative."
 **Expected behavior**:
-- Produces a crisis communication response plan (not just a single tweet)
-- Plan includes: (1) immediate acknowledgment post — acknowledge the feedback without being defensive; (2) timeline for developer response — commit to a specific timeframe for a design team statement; (3) developer statement template — explain the reasoning behind the nerf without dismissing player concerns; (4) follow-up structure — if rollback or adjustment is planned, communicate it with a timeline
-- Does NOT commit to a rollback on behalf of the design team — flags this as a creative-director decision
-- Tone is empathetic but not apologetic for intentional design decisions
+- Produces a crisis communication plan (not just a single post) following its Crisis Communication standards: a fast acknowledgment (within 30 minutes), status updates on a stated cadence, specific rather than vague wording, and a follow-up explaining the change
+- Sources the reasoning behind the nerf from `game-designer`, its contact for explaining gameplay changes to players, rather than inventing it
+- Does NOT commit to a rollback, an adjustment, or a date — "Never promise specific features or dates without producer approval"; whether to roll the nerf back is a design decision it flags to `game-designer` (producer escalates game design changes there), and any public commitment or date still needs producer approval
+- Tone is empathetic and never combative ("Empathetic to player frustration", "Never combative with criticism — even when unfair")
 
 ### Case 4: Brand voice conflict in patch notes
+**Input context**: The loading-screen fix is confirmed in this release's QA record.
 **Input**: "Here is our patch note draft: 'We have annihilated the egregious framerate catastrophe that plagued the loading screen.' Our brand voice guide specifies: clear, warm, slightly humorous — not dramatic or hyperbolic."
 **Expected behavior**:
-- Identifies the conflict: "annihilated," "egregious," and "catastrophe" are dramatic/hyperbolic — inconsistent with the specified brand voice
+- Identifies the conflict: "annihilated," "egregious," and "catastrophe" are dramatic/hyperbolic — against the supplied guide and against its own Patch Notes standards, "Use clear, jargon-free language" and "explain what changed and why it matters to them" (the line never says what changed for players)
 - Does NOT approve the draft as-is
-- Produces a revised version: e.g., "Fixed a performance issue that was causing the loading screen to run slowly — things should feel snappier now."
+- Produces a revised version in the guide's voice: e.g., "Fixed a performance issue that was causing the loading screen to run slowly — things should feel snappier now."
 - Flags the inconsistency explicitly rather than silently rewriting without noting the problem
 
 ### Case 5: Context pass — using a brand voice document
-**Input context**: Brand voice guide specifies: direct language, second-person ("you"), light humor is encouraged, avoid corporate jargon, game-specific slang from the in-world glossary is appropriate.
+**Input context**: Brand voice guide specifies: direct language, second-person ("you"), light humor is encouraged, avoid corporate jargon, game-specific slang from the in-world glossary is appropriate. Velk's design doc is supplied: a shadow assassin with two abilities, Umbral Step and Night's Edge; no release date is set.
 **Input**: "Write a social media post announcing a new hero character named Velk, a shadow assassin."
 **Expected behavior**:
-- Uses second-person address ("Meet your next favorite assassin")
-- Incorporates light humor if it fits naturally
-- Avoids corporate language ("We are pleased to announce" → "Meet Velk")
+- Uses second-person address ("Meet your next favorite assassin"), light humor where it fits, and no corporate language ("We are pleased to announce" → "Meet Velk")
 - Uses in-world language if the context includes a glossary (e.g., if assassins are called "Shadowwalkers" in-world, uses that term)
+- Every claim about Velk comes from the supplied design doc — the two listed abilities, nothing invented ("before listing content, verify it exists")
+- Gives no release date — none is in the source, and dates need producer approval
 - Output matches the specified tone — not a generic press-release announcement
 
 ---
 
 ## Protocol Compliance
 
-- [ ] Stays within declared domain (player-facing communication, patch note text, crisis response, bug routing)
+- [ ] Stays within declared domain (player-facing communication, patch note text, crisis response, feedback triage)
 - [ ] Strips internal IDs, class names, and technical jargon from all player-facing output
-- [ ] Redirects bug fix requests to appropriate programmers rather than attempting technical solutions
-- [ ] Does NOT commit to design rollbacks without creative-director authority
+- [ ] Routes bug-fix requests to the team (qa-lead or a programmer) rather than attempting technical solutions
+- [ ] States that a fix or content exists only with evidence it has seen (code or QA record); an unverifiable claim is omitted, not hedged
+- [ ] Promises no rollback, feature, or date without producer approval
 - [ ] Applies brand voice specifications from context; flags violations rather than silently accepting them
 
 ---
 
 ## Coverage Notes
-- Case 1 (patch note sanitization) is the most frequently used behavior — test on every new patch cycle
+- Case 1 (patch note sanitization and evidence) is the most frequently used behavior — test on every new patch cycle
 - Case 3 (crisis communication) is a brand-safety test — verify the agent de-escalates rather than inflames
 - Case 4 requires a brand voice document to be in context; test is incomplete without it
-- Case 5 is the most important context-awareness test for tone consistency
+- Case 5 is the most important context-awareness test for tone consistency and for sourcing every claim
 - No automated runner; review manually or via `/skill-test`

CCGS Skill Testing Framework/agents/operations/devops-engineer.md

@@ -1,19 +1,19 @@
 # Agent Test Spec: devops-engineer
 
 ## Agent Summary
-- **Domain**: CI/CD pipeline configuration, build scripts, version control workflow enforcement, deployment infrastructure, branching strategy, environment management, automated test integration in CI
-- **Does NOT own**: Game logic or gameplay systems, security audits (security-engineer), QA test strategy (qa-lead), game networking logic (network-programmer)
-- **Model tier**: Sonnet
-- **Gate IDs**: None; escalates deployment blockers to producer
+- **Domain**: CI/CD pipeline configuration, build scripts, version control workflow and branching strategy (trunk-based, per `CLAUDE.md`), release tagging scheme, automated test integration in CI, artifact management, environment management
+- **Does NOT own**: Game code or assets, technology stack decisions and server infrastructure changes (technical-director approves), security audits (security-engineer), QA test strategy (qa-lead), game networking logic (network-programmer)
+- **Gate IDs**: None; reports to technical-director and escalates build-time and infrastructure concerns there
 
 ---
 
 ## Static Assertions (Structural)
 
 - [ ] `description:` field is present and domain-specific (references CI/CD, build, deployment, version control)
-- [ ] `allowed-tools:` list matches the agent's role (Read/Write for pipeline config files, shell scripts, YAML; no game source editing tools)
-- [ ] Model tier is Sonnet (default for operations specialists)
+- [ ] `tools:` reads `Read, Glob, Grep, Write, Edit, Bash` — Bash to run builds and pipelines; game code and assets are excluded by the body's "What This Agent Must NOT Do" list, not by the tool list
+- [ ] Model tier is `sonnet` — frontmatter `model:` reads exactly `sonnet` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition does not claim authority over game logic, security audits, or QA test design
+- [ ] Its Implementation Workflow questions are pipeline questions (which platforms, engine version and export presets CI builds; where build secrets and signing keys live) — none asks how game code should be structured
 
 ---
 
@@ -23,58 +23,61 @@
 **Input**: "Set up a CI pipeline for our Godot 4 project. It should run tests on every push to main and every pull request, and fail the build if tests fail."
 **Expected behavior**:
 - Produces a GitHub Actions workflow YAML (`.github/workflows/ci.yml` or equivalent)
-- Uses the Godot headless test runner command from `coding-standards.md`: `godot --headless --script tests/gdunit4_runner.gd`
+- Uses the Godot headless test runner command from `coding-standards.md`: `godot --headless -s -d --remote-debug tcp://127.0.0.1:0 res://addons/gdUnit4/bin/GdUnitCmdTool.gd -a res://tests --ignoreHeadlessMode`
 - Configures trigger on `push` to main and `pull_request`
-- Sets the job to fail (`exit 1` or non-zero exit) when tests fail — does NOT configure the pipeline to continue on test failure
-- References the project's coding standards CI rules in the output or comments
+- Sets the job to fail (non-zero exit) when tests fail — does NOT add `continue-on-error` or any other setting that lets the pipeline pass on a test failure
+- Shows the workflow and asks "May I write this to `.github/workflows/<file>`?" before writing it (Collaboration Protocol, step 5)
 
 ### Case 2: Out-of-domain request — game networking implementation
 **Input**: "Implement the server-authoritative movement system for our multiplayer game."
 **Expected behavior**:
-- Does not produce game networking or movement code
-- States clearly: "Game networking implementation is owned by network-programmer; I handle the infrastructure that builds, tests, and deploys the game"
+- Does not produce game networking or movement code — "Modify game code or assets" is on its "What This Agent Must NOT Do" list
+- Says the work belongs to a programmer and names who takes it: `lead-programmer` or `technical-director`, the agents its file names (naming `network-programmer`, the owner of netcode, also satisfies this)
+- States what it can do instead: the infrastructure that builds, tests, and deploys the game once the netcode exists
 - Does not conflate CI pipeline configuration with in-game network architecture
 
 ### Case 3: Build failure diagnosis
 **Input**: "Our CI pipeline is failing on the merge step. The error is: 'Asset import failed: texture compression format unsupported in headless mode.'"
 **Expected behavior**:
-- Diagnoses the root cause: headless CI environment does not support GPU-dependent texture compression
-- Proposes a concrete fix: either pre-import assets locally before CI runs (commit .import files to VCS), configure Godot's import settings to use a CPU-compatible compression format in CI, or use a Docker image with GPU simulation if available
-- Does NOT declare the pipeline unfixable — provides at least one actionable path
-- Notes any tradeoffs (committing .import files increases repo size; CPU compression may differ from GPU output)
+- Diagnoses the failure as an environment problem in the headless CI runner (the import step needs a capability the headless runner lacks), not a flaky step to retry
+- Before stating how Godot 4.6 imports or compresses textures headlessly, cross-references `docs/engine-reference/godot/` — `VERSION.md` pins 4.6, past the model's training data — and says so when the reference does not cover it, rather than asserting version-specific behavior from memory
+- Proposes at least one actionable fix that keeps the import and test steps in the pipeline, and names its tradeoff
+- Does NOT remove the import step, skip the tests, or mark the job `continue-on-error` to get a green build — "Skip CI steps for speed" is forbidden, and `coding-standards.md` says "Never disable or skip failing tests to make CI pass — fix the underlying issue"
+- Does NOT declare the pipeline unfixable
 
 ### Case 4: Branching strategy conflict
 **Input**: "Half the team wants to use GitFlow with long-lived feature branches. The other half wants trunk-based development. How should we set this up?"
 **Expected behavior**:
-- Recommends trunk-based development per project conventions (CLAUDE.md / coordination-rules.md specify Git with trunk-based development)
-- Provides concrete rationale for the recommendation in this project's context: smaller team, fewer integration conflicts, faster CI feedback
-- Does NOT present this as a 50/50 choice if the project has an established convention
-- Explains how to implement trunk-based development with short-lived feature branches and feature flags if needed
-- Does NOT override the project convention without flagging that doing so requires updating CLAUDE.md
+- Recommends trunk-based development because `CLAUDE.md` names it under Version Control ("Git with trunk-based development"), and says that is the model it followed
+- Explains the model as its Branching Strategy section defines it: `main` is the always-shippable trunk, built and tested by CI on every push and pull request; work happens on short-lived branches merged back within a day or two through a pull request that passes CI; unfinished work ships dark behind a feature flag
+- Rejects GitFlow's long-lived branches specifically — there is no long-lived integration branch beside `main`
+- Covers releases and hotfixes per the same section: a release is a tag on `main`; a `release/*` branch is cut only to stabilise a release (bug fixes only, every fix also lands on `main`); a `hotfix/*` branch starts from the release tag (or its `release/*` branch, if one exists) and merges back to `main`, and to that `release/*` branch only if it exists
+- Does NOT present this as a 50/50 choice, and does not adopt GitFlow on its own authority — the model comes from `CLAUDE.md`'s Version Control line, so switching means changing that line
 
 ### Case 5: Context pass — platform-specific build matrix
-**Input context**: Project targets PC (Windows, Linux), Nintendo Switch, and PlayStation 5.
+**Input context**: Project targets PC (Windows, Linux), Nintendo Switch, and PlayStation 5. CI runs on GitHub-hosted runners, which have no console export templates or SDKs installed.
 **Input**: "Set up our CI build matrix so we get a build artifact for each target platform on every release branch push."
 **Expected behavior**:
-- Produces a build matrix configuration with three platform entries: Windows, Linux, Switch, PS5
-- Applies platform-appropriate build steps: PC uses standard Godot export templates; Switch and PS5 require platform-specific export templates (notes that console templates require licensed SDK access and are not publicly distributed)
-- Does NOT assume all platforms can use the same build runner — flags that console builds may require self-hosted runners with licensed SDKs
-- Organizes artifacts by platform name in the pipeline output
+- Produces a build matrix configuration with four platform entries — Windows, Linux, Switch, PS5 — each a one-command build (Build Pipeline)
+- Triggers release builds the way its Branching Strategy defines a release: on release tags on `main`, and on pushes to a `release/*` branch while one exists for stabilisation — and says why, rather than assuming a standing release branch
+- Does NOT provision new build infrastructure for the console entries (e.g., self-hosted runners with the platform SDKs) on its own — "Change server infrastructure without technical-director approval" is forbidden, so it flags the requirement for technical-director approval instead of silently writing it into the config
+- Organizes artifacts by platform name, with versioning and retention (Artifact Management)
 
 ---
 
 ## Protocol Compliance
 
-- [ ] Stays within declared domain (CI/CD, build scripts, version control, deployment)
-- [ ] Redirects game logic and networking requests to appropriate programmers
-- [ ] Recommends trunk-based development when branching strategy is contested, per project conventions
-- [ ] Returns structured pipeline configurations (YAML, scripts) not freeform advice
-- [ ] Flags platform SDK licensing constraints for console builds rather than silently producing incorrect configs
+- [ ] Stays within declared domain (CI/CD, build scripts, version control, artifacts, environments)
+- [ ] Declines game code and networking requests and names who takes them (`lead-programmer` / `technical-director`, or the owning programmer)
+- [ ] Recommends trunk-based development when branching strategy is contested, citing `CLAUDE.md`'s Version Control line
+- [ ] Returns structured pipeline configurations (YAML, scripts), not freeform advice, and asks before writing them
+- [ ] Never skips CI or test steps to get a green build, and routes infrastructure changes to technical-director for approval
 
 ---
 
 ## Coverage Notes
-- Case 1 (Godot CI) references `coding-standards.md` CI rules — verify this file is present and current before running this test
+- Case 1 references `coding-standards.md` CI rules — verify this file is present and current before running this test
+- Case 3 tests that the agent consults `docs/engine-reference/godot/` for version-specific behavior; it does not require the reference to cover headless import
 - Case 4 (branching strategy) is a convention-enforcement test — agent must know the project convention, not just give neutral advice
-- Case 5 requires that project's target platforms are documented (in `technical-preferences.md` or equivalent)
+- Case 5 supplies the target platforms in context; in a real project they come from `project.yaml`
 - No automated runner; review manually or via `/skill-test`

CCGS Skill Testing Framework/agents/operations/economy-designer.md

@@ -1,18 +1,17 @@
 # Agent Test Spec: economy-designer
 
 ## Agent Summary
-- **Domain**: Resource economy design, loot table design, progression curves (XP, level, unlock), in-game market and shop design, economic balance analysis, sink and faucet mechanics, inflation/deflation risk assessment
-- **Does NOT own**: Live ops event scheduling and structure (live-ops-designer), code implementation, analytics tracking design (analytics-engineer), narrative justification for economy systems (writer)
-- **Model tier**: Sonnet
-- **Gate IDs**: None; escalates economy-breaking design conflicts to creative-director or producer
+- **Domain**: Resource economy design, loot table design, progression curves (XP, level, unlock), in-game market and shop design, economic balance analysis, sink and faucet mechanics, inflation/deflation risk assessment, entity registry values for items and currencies
+- **Does NOT own**: Live ops event scheduling and structure (live-ops-designer), core gameplay mechanics (game-designer), code implementation, analytics tracking design (analytics-engineer), narrative justification for economy systems (writer)
+- **Gate IDs**: None; reports to game-designer; monetization decisions need creative-director approval
 
 ---
 
 ## Static Assertions (Structural)
 
 - [ ] `description:` field is present and domain-specific (references economy, loot tables, progression curves, balance)
-- [ ] `allowed-tools:` list matches the agent's role (Read/Write for design/balance/ 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 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 live ops scheduling, code, or narrative
 
 ---
@@ -22,11 +21,12 @@
 ### Case 1: In-domain request — loot table design for a chest
 **Input**: "Design the loot table for a standard treasure chest in our dungeon game."
 **Expected behavior**:
-- Produces a probability table with distinct rarity tiers: Common, Uncommon, Rare, Epic, Legendary (or project-equivalent tiers)
-- Each tier has: probability percentage, example item categories, and expected gold equivalent value range
-- Probabilities sum to 100%
-- Includes a brief rationale for each tier's probability: why Common is set at its value, why Legendary is set at its value
-- Does NOT produce a single flat list of items — uses tiered probability structure to reflect meaningful rarity
+- Before drafting, asks clarifying questions and presents 2-4 options with a recommendation (Question-First Workflow) — e.g. tier names, whether chests use pity timers or bad-luck protection
+- Reads `design/registry/entities.yaml` before authoring and uses registered item values as canonical; a value that differs from a registered entry is flagged as a proposed registry change, not silently used
+- Produces the table in its Reward Output Format (output, rate or weight, condition, notes) with distinct rarity tiers — Common, Uncommon, Rare, Epic, Legendary, or project-equivalent — not a single flat list of items
+- Tier rates form a complete distribution: percentages sum to 100%, or weights are given with their total
+- States the expected acquisition for each tier (attempts on average to receive it) and names the reward-schedule principle behind the table (Reward Psychology)
+- Offers to register new cross-system items: "May I add them to `design/registry/entities.yaml`?"
 
 ### Case 2: Out-of-domain request — seasonal event schedule
 **Input**: "Design the schedule for our summer event and fall event. When should they run and how long should each last?"
@@ -49,16 +49,16 @@
 **Expected behavior**:
 - Identifies this as a progression curve problem: the XP cost growth rate outpaces the reward growth rate
 - Produces a revised XP formula or curve adjustment: either reduce the XP cost multiplier for levels 20-35, increase reward XP in that range, or introduce a catch-up mechanic (bonus XP for completing content significantly below the player's level)
-- Shows the math: current curve vs. proposed curve, with specific numbers for levels 20, 25, 30, 35
-- Flags that any curve change affects time-to-level-cap projections — notes the downstream impact on end-game content pacing
+- States the current and proposed curves as formulas with defined variables and evaluates both across the 20–35 range, both ends included (e.g., at levels 20, 25, 30 and 35) — `coding-standards.md` requires design math "defined with variables" and balance values linked to their source formula
+- Flags that any curve change affects time-to-level-cap projections — notes the downstream impact on end-game content pacing (its Progression Curve Design models expected player power at each stage)
 
 ### Case 5: Context pass — balance analysis using current economy data
 **Input context**: Current economy data: average player earns 450 Gold/hour, average shop item costs 2,000 Gold, average session length is 40 minutes. Premium items cost 5,000 Gold.
 **Input**: "Is our current Gold economy healthy? Should we adjust prices or earn rates?"
 **Expected behavior**:
-- Uses the specific numbers provided: 450 Gold/hour = 300 Gold/40-min session; 2,000 Gold item requires ~4.4 sessions to afford; 5,000 Gold premium item requires ~11 sessions
-- Evaluates whether these ratios feel rewarding or frustrating based on economy design principles
-- Produces a concrete recommendation using the actual numbers: e.g., "At current earn rates, premium items take ~7.3 hours of play to afford — this is at the high end of acceptable; consider either increasing earn rate to 550 Gold/hour or reducing premium item cost to 4,000 Gold"
+- Uses the specific numbers provided: 450 Gold/hour = 300 Gold per 40-minute session; a 2,000 Gold item takes ~4.4 hours (~6.7 sessions) to afford; a 5,000 Gold premium item takes ~11.1 hours (~16.7 sessions)
+- Evaluates those acquisition times against its Economic Health Metrics (average currency per hour, item acquisition rate)
+- Presents options anchored to the numbers — e.g. raise the earn rate or lower the premium price — with the resulting hours and sessions for each, makes a recommendation, and leaves the choice to the user (Question-First Workflow)
 - Does NOT produce generic advice ("prices may be too high") without anchoring to the provided data
 
 ---
@@ -68,12 +68,15 @@
 - [ ] Stays within declared domain (loot tables, progression curves, resource economy, inflation/deflation analysis)
 - [ ] Redirects live ops scheduling requests to live-ops-designer without producing schedules
 - [ ] Flags inflation/deflation risks proactively with quantified sink/faucet analysis
-- [ ] Produces explicit math for progression curves — no vague curve adjustments without numbers
+- [ ] States progression-curve changes as formulas with defined variables and worked numbers — no vague curve adjustments
 - [ ] Uses actual economy data from context; does not produce generic benchmarks when specifics are provided
+- [ ] Checks `design/registry/entities.yaml` before authoring items and flags any change to a registered value
+- [ ] Asks "May I create [filepath] with the section skeleton?" before creating a multi-section document, and "May I write this section to [filepath]?" before writing each section
 
 ---
 
 ## Coverage Notes
+- Case 1 exercises Registry Awareness — include `design/registry/entities.yaml` in the fixture
 - Case 3 (inflation risk) is an economic health test — missed inflation risks cause long-term economy damage in live games
 - Case 4 requires the agent to produce actual numbers, not curve shapes — verify math is present, not just a narrative
 - Case 5 is the most important context-awareness test; agent must use provided data, not placeholder values

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
 

CCGS Skill Testing Framework/agents/operations/localization-lead.md

@@ -1,18 +1,17 @@
 # Agent Test Spec: localization-lead
 
 ## Agent Summary
-- **Domain**: Internationalization (i18n) architecture, string extraction workflows and tooling configuration, locale testing methodology, translation pipeline design (extraction → TMS → import), string quality standards, locale-specific formatting rules (plurals, RTL, date/number formats)
-- **Does NOT own**: Game narrative content and dialogue writing (writer), code implementation of i18n calls (gameplay-programmer), translation work itself (external translators)
-- **Model tier**: Sonnet
-- **Gate IDs**: None; escalates pipeline architecture decisions to technical-director when they affect build systems
+- **Domain**: Internationalization (i18n) architecture, string extraction workflows, locale testing methodology, translation pipeline design (extraction → translation → import), string key and context standards, locale-specific formatting rules (plurals, RTL, date/number formats), fonts and character sets, glossary and translation memory
+- **Does NOT own**: Game narrative content and dialogue writing (writer), translation work itself (translators), UI design decisions (ux-designer), game design decisions (game-designer), which languages to support (producer); it coordinates text rendering and RTL support with ui-programmer and extraction automation with tools-programmer
+- **Gate IDs**: None; reports to producer for scheduling, language support scope, and budget
 
 ---
 
 ## Static Assertions (Structural)
 
 - [ ] `description:` field is present and domain-specific (references i18n, string extraction, locale pipeline, localization)
-- [ ] `allowed-tools:` list matches the agent's role (Read/Write for localization config, pipeline docs, string tables; no game source editing or deployment tools)
-- [ ] Model tier is Sonnet (default for specialists)
+- [ ] `tools:` reads `Read, Glob, Grep, Write, Edit, Bash` — Bash for string-extraction tooling; writing translations and narrative content is excluded by the body's "What This Agent Must NOT Do" list, not by the tool list
+- [ ] Model tier is `inherit` — frontmatter `model:` reads exactly `inherit` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition does not claim authority over narrative content, game code implementation, or translation quality
 
 ---
@@ -22,34 +21,35 @@
 ### Case 1: In-domain request — string extraction pipeline for a Unity project
 **Input**: "Set up a string extraction pipeline for our Unity game. We need to get all localizable strings into a format translators can work with."
 **Expected behavior**:
-- Produces a concrete extraction configuration covering: which string types to extract (UI labels, dialogue, item descriptions — not debug strings), the tool to use (e.g., Unity Localization package string tables, or a custom extraction script targeting specific component types), and the output format (CSV, XLIFF, or TMX — notes which formats are compatible with common TMS tools like Crowdin or Lokalise)
-- Specifies the folder structure: e.g., `assets/localization/en/` as the source locale, `assets/localization/{locale}/` for translated files
-- Notes that string keys must be stable (do not use index-based keys) — key changes break all existing translations
-- Does NOT produce Unity C# code for the i18n implementation — marks as [TO BE IMPLEMENTED BY PROGRAMMER]
+- Lays out the workflow its String Extraction Workflow defines: strings enter through the localization API (never raw text), land in the base locale file with a context comment, extraction tooling collects new and modified strings, and they go to translators with context, screenshots, and character limits, then come back into the locale files
+- Scopes extraction to player-facing text from code, UI, and content — "Ensure no hardcoded strings reach production"
+- Specifies structured locale files (JSON, CSV, or a project-appropriate format), one file per language per system or feature area (the `locales/en/ui_menu.json` pattern)
+- Uses hierarchical dot-notation keys that describe context (`menu.settings.audio.volume_label`) — not positional or index-based keys — each with a context comment giving where it appears, its character limit, and its variables
+- Names `tools-programmer` for the extraction automation and `ui-programmer` for text rendering (Delegation Map), and asks before writing any pipeline document
 
 ### Case 2: Out-of-domain request — translate game dialogue
 **Input**: "Translate the following English dialogue into French: 'Well met, traveler. The road ahead is treacherous.'"
 **Expected behavior**:
 - Does not produce a French translation
-- States clearly: "localization-lead owns the pipeline, quality standards, and workflow; actual translation work is performed by human translators or approved translation vendors — I am not a translator"
+- States that it owns the pipeline, quality standards and workflow, and that translation itself is done by human translators or approved vendors (its "Write actual translations" must-not line)
 - Optionally notes what information a translator would need: context (who is speaking, to whom, game genre/tone), character limit constraints if any, glossary terms (e.g., if "traveler" has a game-specific translation)
 
 ### Case 3: Domain boundary — missing plural forms in Russian locale
 **Input**: "Our Russian locale files only have a singular form for item quantity strings. Russian requires multiple plural forms (1 item, 2-4 items, 5+ items use different forms)."
 **Expected behavior**:
-- Identifies this as a locale-specific plural form gap: Russian has 3 plural categories (one, few, many) per CLDR/Unicode plural rules — a single string is insufficient
+- Identifies this as a locale-specific plural form gap: CLDR/Unicode plural rules give Russian four categories — one, few, many and other (`other` covers fractional quantities, and ICU MessageFormat requires it in every plural message) — so a single string is insufficient
 - Flags it as a localization quality bug, not a minor style issue — incorrect plural forms are grammatically wrong and visible to players
-- Recommends the fix: update the string extraction format to support CLDR plural categories (one/few/many/other), and flag to the translation vendor that Russian strings need all plural forms
-- Notes which other languages in the pipeline also require plural form support (e.g., Polish, Czech, Arabic)
-- Does NOT suggest using a numeric threshold workaround as a substitute for proper CLDR plural support
+- Recommends the fix its Pluralization standard names: plural rules through ICU MessageFormat (or equivalent) with the language's plural categories, and flags to the translators that Russian strings need every plural form
+- Treats it as a pipeline-wide fix — quantity strings in every supported locale move to ICU plural rules — not a Russian-only patch (Polish, Czech, and Arabic have the same problem)
+- Does NOT suggest using a numeric threshold workaround as a substitute for proper plural rules
 
 ### Case 4: String key naming conflict between two systems
 **Input**: "Our UI system uses keys like 'button_confirm' and 'button_cancel'. Our dialogue system uses 'confirm' and 'cancel' for the same concepts. Translators are confused about which to use."
 **Expected behavior**:
 - Identifies the conflict: two systems use different key naming conventions for semantically identical strings, creating duplicate translation work and translator confusion
-- Produces a naming convention resolution: domain-prefixed keys with a consistent separator (e.g., `ui.button.confirm`, `ui.button.cancel`) — all systems use the same key for shared concepts
-- Recommends that shared UI primitives (Confirm, Cancel, Back, OK) use a single canonical key in a shared namespace, referenced by both systems
-- Provides a migration path: map old keys to new keys, update all string references in both systems, deprecate old keys after one release cycle
+- Produces a naming convention resolution in its hierarchical dot-notation standard (e.g., `ui.button.confirm`, `ui.button.cancel`) — all systems use the same key for shared concepts
+- Recommends that shared UI primitives (Confirm, Cancel, Back, OK) use a single canonical key in a shared namespace, referenced by both systems, and records the terms in the glossary
+- Plans the key change so nothing breaks: every reference in both systems moves to the new key, no lookup is left pointing at a retired key (its Key naming convention rule, and Fallback chains: "never display raw keys to players"), existing translations carry over through translation memory, and the code change in both systems is coordinated with their owners before it is made
 - Does NOT recommend maintaining two separate keys for the same concept
 
 ### Case 5: Context pass — pipeline accommodates RTL languages
@@ -57,10 +57,10 @@
 **Input**: "Design the localization pipeline for this project."
 **Expected behavior**:
 - Identifies Arabic and Hebrew as RTL languages — explicitly calls this out as a pipeline requirement
-- Designs the pipeline to include: RTL text rendering support (flag for programmer: UI must support RTL layout mirroring), bidirectional (bidi) text handling in string tables, locale-specific testing checklist entry for RTL layout
+- Designs the pipeline to include its RTL requirements: mirrored UI layout, bidirectional text in the same string, numbers kept LTR inside RTL text, flipped directional UI, and testing with native RTL speakers — with RTL rendering coordinated with `ui-programmer`
 - Does NOT design a pipeline that only accounts for LTR languages when RTL locales are specified
-- Notes that Arabic also requires a different plural form structure (6 plural categories in CLDR) — flags for translation vendor
-- Output includes all five locales in the pipeline architecture, not just the default (en)
+- Covers the Arabic/Hebrew font needs (RTL shaping, ligatures, contextual forms) and plural rules through ICU MessageFormat for every locale
+- Includes all five locales: a fallback chain, and its Locale-Specific Testing Requirements (dates, numbers, currency, time, sorting, input, text rendering) applied to each language, not just the default (en)
 
 ---
 
@@ -69,7 +69,7 @@
 - [ ] Stays within declared domain (pipeline, extraction, string quality, locale formats, i18n architecture)
 - [ ] Does not produce translations — redirects translation work to human translators/vendors
 - [ ] Flags locale-specific gaps (plural forms, RTL) as quality bugs requiring pipeline changes
-- [ ] Produces a unified key naming convention when conflicts arise — does not accept dual conventions
+- [ ] Produces a unified key naming convention when conflicts arise, migrated so no lookup is left on a retired key — does not accept dual conventions
 - [ ] Incorporates all provided target locales, including RTL languages, into pipeline design
 
 ---
@@ -77,5 +77,5 @@
 ## Coverage Notes
 - Case 3 (plural forms) and Case 5 (RTL) are locale-correctness tests — these affect shipping quality in non-English markets
 - Case 4 (key naming conflict) is a pipeline hygiene test — duplicate keys cause ongoing translator confusion and cost
-- Case 5 requires the target locale list to be in context; if not provided, agent should ask before designing the pipeline
+- Case 5 requires the target locale list to be in context; if it is not provided, the agent should ask rather than choose — which languages to support is producer's decision
 - No automated runner; review manually or via `/skill-test`

CCGS Skill Testing Framework/agents/operations/release-manager.md

@@ -1,80 +1,83 @@
 # Agent Test Spec: release-manager
 
 ## Agent Summary
-- **Domain**: Release pipeline management, platform certification checklists (Nintendo, Sony, Microsoft, Apple, Google), store submission workflows, platform technical requirements compliance, semantic version numbering, release branch management
-- **Does NOT own**: Game design decisions, QA test strategy or test case design (qa-lead), QA test execution (qa-tester), build infrastructure (devops-engineer)
-- **Model tier**: Sonnet
-- **Gate IDs**: May be invoked by `/gate-check` during Release phase; LAUNCH BLOCKED verdict is release-manager's primary escalation output
+- **Domain**: Release pipeline (Build → Test → Cert → Submit → Verify → Launch), platform certification checklists scoped by `platform.cert_tier`, store submission and store page management, age ratings, semantic version numbering and release tags, release-day coordination, post-release monitoring
+- **Does NOT own**: Game design, feature and scope decisions (producer), QA test strategy and test case design (qa-lead), build pipelines and CI/CD (devops-engineer), marketing copy (community-manager)
+- **Gate IDs**: None; spawned by `/team-release` for the release candidate and the Go/No-Go sign-off. Its blocking output is a `NOT READY` Go/No-Go verdict from the preloaded `/release-checklist`, reported to producer
 
 ---
 
 ## Static Assertions (Structural)
 
 - [ ] `description:` field is present and domain-specific (references release pipeline, certification, store submission)
-- [ ] `allowed-tools:` list matches the agent's role (Read/Write for production/releases/ directory; no game source or test tools)
-- [ ] Model tier is Sonnet (default for operations specialists)
+- [ ] `tools:` reads `Read, Glob, Grep, Write, Edit, Bash` — Bash for release tagging ("Version tags must be applied to the git repository at every release point")
+- [ ] `skills:` preloads `release-checklist`, `changelog` and `patch-notes`
+- [ ] Model tier is `inherit` — frontmatter `model:` reads exactly `inherit` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition does not claim authority over QA strategy, game design, or build infrastructure
+- [ ] Its next-step offer runs `/patch-notes [version]` itself and hands the result to community-manager for the announcement — never a brief for community-manager to write the patch notes
+- [ ] The pipeline's Test step takes the release gate's tier: QA sign-off at `workflow: full` (recommended at `standard`), no open S1 at any tier, no open S2 or S3 either at `full`
 
 ---
 
 ## Test Cases
 
-### Case 1: In-domain request — platform certification checklist for Nintendo Switch
+### Case 1: In-domain request — certification checklist for a console submission
+**Input context**: `project.yaml` sets `platform.cert_tier: console`; the game ships on Nintendo Switch.
 **Input**: "Generate the certification checklist for our Nintendo Switch submission."
 **Expected behavior**:
-- Produces a structured checklist covering Nintendo Lotcheck requirements relevant to the game type
-- Includes categories: content rating (CERO/PEGI/ESRB as applicable), save data handling, offline mode compliance, error handling (lost connectivity, storage full), controller requirement (Joy-Con, Pro Controller support), sleep/wake behavior, screenshot/video capture compliance
-- Formats output as a numbered checklist with pass/fail columns
-- Notes that Nintendo's full Lotcheck guidelines require a licensed developer account to access and flags any items that require manual verification against the current guidelines document
-- Does NOT produce fabricated requirement IDs — uses known public requirements or clearly marks uncertainty
+- Emits the console certification block its preloaded `/release-checklist` defines for `cert_tier: console` — TRC/TCR/Lotcheck requirements checklist, first-party submission, achievement/trophy integration, parental controls, save-data rules (corruption, full storage, user switching), age ratings — plus the console device requirements (controller prompts, suspend/resume, user switching, connectivity loss, storage full)
+- Tracks every requirement individually with pass / fail / not-applicable status (Platform Certification Requirements)
+- Emits no itch.io or Steamworks certification rows — the certification block follows `cert_tier`, not the platform named in the request
+- Ends with the Go / No-Go line in `/release-checklist`'s three words (READY / NOT ASSESSED / NOT READY, first match wins) — here NOT ASSESSED or NOT READY, never READY, because the fixture supplies no build or test evidence — and asks "May I write this to `production/releases/release-checklist-[version].md`?" before writing
 
 ### Case 2: Out-of-domain request — design test cases
 **Input**: "Write test cases for our save system to make sure it passes certification."
 **Expected behavior**:
 - Does not produce test case specifications
-- States clearly: "Test case design is owned by qa-lead (strategy) and qa-tester (execution); I can provide the certification requirements that the save system must meet, which qa-lead can then use to design tests"
-- Optionally offers to list the save-system-relevant certification requirements
+- Routes test design to `qa-lead`, which its Delegation Map names for quality gates, test results, and release readiness sign-off
+- Offers what it does own: the save-data certification requirements the tests must cover (the console block's "Save-data rules compliant (corruption, full storage, user switching)"), as input for qa-lead
 
-### Case 3: Domain boundary — certification failure (rating issue)
+### Case 3: Domain boundary — age-rating rejection blocks the release
 **Input**: "Our build was rejected by the ESRB. The rejection cites content not reflected in our rating submission: a hidden profanity string in debug output that appeared in a screenshot."
 **Expected behavior**:
-- Issues a LAUNCH BLOCKED verdict with the specific platform requirement referenced (ESRB submission accuracy requirement)
-- Identifies the immediate action required: locate and remove all debug output containing inappropriate content before resubmission
-- Notes the resubmission process: corrected build must be resubmitted with updated content descriptor if needed
-- Does NOT minimize the issue — a certification rejection is a blocking event, not an advisory
-- Escalates to producer: documents the delay impact on release timeline
+- Treats the rejection as blocking: the pipeline halts at the failed step until the issue is resolved ("No step may be skipped. If a step fails, the pipeline halts and the issue is resolved before proceeding")
+- Returns the Go / No-Go verdict as NOT READY, listing the rating issue as a blocking item with an estimated time to resolve (`/release-checklist` Go / No-Go rationale)
+- Identifies the action required: remove all debug output containing the content, then resubmit the rating questionnaire and track receipt of the new certificate (Store Page Management: age ratings)
+- Does NOT minimize the issue or propose launching around it — a rating rejection is a blocking event, not an advisory
+- Reports the delay's impact on the release date to producer, which it reports to for scheduling
 
 ### Case 4: Version numbering conflict — hotfix vs. release branch
 **Input**: "Our release branch is at v1.2.0. A hotfix was applied directly on main and tagged v1.2.1. Now the release branch also has changes that need to ship as v1.2.1 but they're different changes."
 **Expected behavior**:
-- Identifies the conflict: two different changesets have been assigned the same version tag
-- Applies semantic versioning resolution: one must be re-tagged — the release branch changes should become v1.2.2 if v1.2.1 is already published; if v1.2.1 is not yet published, coordinate with devops-engineer to merge or re-tag
-- Does NOT accept a state where the same version number refers to two different builds
-- Notes that once a version is submitted to a store, it cannot be reused — flags this as a potential store submission blocker
+- Identifies the conflict: two different changesets have been assigned the same version
+- Resolves it with semantic versioning: `v1.2.1` stays with the build it already tags, and the release branch's changes, being fixes, ship as the next PATCH (`v1.2.2`) — its Version Numbering rule for two changesets claiming one version
+- Does NOT accept a state where one version number names two different builds — "an applied tag is never moved or reused", and internal builds stay distinguishable by `MAJOR.MINOR.PATCH.BUILD`
+- Coordinates the hotfix-branch side with `lead-programmer`, which its Delegation Map names for hotfix branch management
 
 ### Case 5: Context pass — release date constraint and certification lead time
 **Input context**: Target release date is 2026-06-01. Current date is 2026-04-06. Nintendo Lotcheck typically takes 4-6 weeks.
 **Input**: "What should we prioritize on the certification checklist given our timeline?"
 **Expected behavior**:
-- Calculates the available window: ~8 weeks to release date; Nintendo Lotcheck at 4-6 weeks means submission must be ready by approximately 2026-04-20 to 2026-05-04 to allow for a potential resubmission cycle
-- Flags that a single rejection cycle would consume the buffer — prioritizes items historically associated with Lotcheck rejections (save data, offline mode, error handling)
-- Orders the checklist by certification lead time impact, not by perceived difficulty
-- Does NOT produce a checklist that assumes first-pass certification — builds in resubmission time
+- Works from the supplied dates and lead time, not placeholders: 8 weeks to release, so the first Lotcheck submission is due between 2026-04-20 (if it takes 6 weeks) and 2026-05-04 (if it takes 4) — before any resubmission
+- Keeps the pipeline order and every step — Build → Test → Cert → Submit → Verify → Launch, "No step may be skipped" — and schedules backward from the release date rather than compressing or dropping a step to fit
+- Plans for at least one certification iteration (Cert is "Submit to platform certification, track feedback, iterate") and flags that a single rejection would consume the remaining buffer
+- Recommends an order but hands the schedule call to `producer` — it reports to producer for scheduling and prioritization, and cutting scope is producer's ("Decide what features to include or exclude (escalate to producer)")
 
 ---
 
 ## Protocol Compliance
 
 - [ ] Stays within declared domain (release pipeline, certification checklists, version numbering, store submission)
-- [ ] Redirects test case design requests to qa-lead/qa-tester without producing test specs
-- [ ] Issues LAUNCH BLOCKED verdicts for certification failures — does not downgrade to advisory
-- [ ] Applies semantic versioning correctly and flags version conflicts as store-blocking issues
-- [ ] Uses provided timeline data to prioritize checklist items by certification lead time
+- [ ] Routes test case design requests to qa-lead without producing test specs
+- [ ] Returns NOT READY for a certification or rating failure and halts the pipeline — does not downgrade to advisory
+- [ ] Applies semantic versioning and never lets one version number name two builds
+- [ ] Scopes certification to `platform.cert_tier` and schedules from provided dates without skipping pipeline steps
 
 ---
 
 ## Coverage Notes
-- Case 3 (LAUNCH BLOCKED verdict) is the most critical test — this agent's primary safety output is blocking bad launches
+- Case 3 (NOT READY on a rating rejection) is the most critical test — this agent's primary safety output is blocking bad launches
+- Case 1 assumes `platform.cert_tier: console`; with the key unset, the expected output is a question about which platforms are in scope or `NOT ASSESSED — cert tier unknown`, never every certification track
 - Case 5 requires current date and release date context; verify the agent uses actual dates, not placeholder estimates
 - Certification requirements change over time — flag if the agent produces specific requirement IDs that may be outdated
 - No automated runner; review manually or via `/skill-test`