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/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`