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/skills/team/team-release.md

@@ -4,11 +4,21 @@
 
 Orchestrates the release team through a 7-phase pipeline from release candidate to
 deployment and post-release monitoring. Coordinates release-manager, qa-lead,
-devops-engineer, producer, security-engineer (optional, required for online/
-multiplayer), network-programmer (optional, required for multiplayer),
-analytics-engineer, and community-manager. Phase 3 agents run in parallel. Ends
-with a go/no-go decision; deployment (Phase 6) is skipped if the producer calls
-NO-GO. Closes with a post-release monitoring plan.
+devops-engineer, producer, security-engineer (required for online/multiplayer/player
+data), network-programmer (required for multiplayer), analytics-engineer,
+localization-lead, performance-analyst and community-manager. Phase 0 resolves
+`review_mode`, `automation`, `team.size`, `workflow` and `project.stage`.
+`/gate-check release` is the readiness gate that must pass before a release, so
+when `project.stage` is not `Release` the skill stops before Phase 1, spawns
+nothing, says "run `/gate-check release` first", and offers an explicit override
+that is recorded (`Stage override: …`) in the go/no-go record and the report — it
+never sets `project.stage` itself. The skill announces the active set before
+Phase 1 — the default `individual` spawns release-manager alone. Each agent writes
+to its own named file under `production/releases/` (patch notes under
+`docs/patch-notes/`). Phase 3 agents run in parallel. Ends with a go/no-go
+decision; deployment (Phase 6) is skipped if the producer calls NO-GO and, on GO,
+still requires an explicit `AskUserQuestion` approval in every automation mode.
+Closes with a post-release monitoring plan.
 
 ---
 
@@ -17,14 +27,21 @@ NO-GO. Closes with a post-release monitoring plan.
 - [ ] Has required frontmatter fields: `name`, `description`, `argument-hint`, `user-invocable`, `allowed-tools`
 - [ ] Has ≥2 phase headings
 - [ ] Contains verdict keywords: COMPLETE, BLOCKED
-- [ ] Contains "May I write" language in the File Write Protocol section (delegated to sub-agents)
-- [ ] Has a File Write Protocol section stating that the orchestrator does not write files directly
-- [ ] Has an Error Recovery Protocol section with four recovery options (surface / assess / offer options / partial report)
-- [ ] Has a next-step handoff referencing post-release monitoring, `/retrospective`, and `production/stage.txt`
+- [ ] File Write Protocol distinguishes sub-agents (bounded exception: named path, new artifact under `production/`, `docs/` or `tests/`, gated phase — no per-write prompt) from sub-skills (normal protocol — they ask before writing), and requires explicit confirmation for tags, pushes, builds and storefront changes
+- [ ] File Write Protocol section states that the orchestrator does not write files directly
+- [ ] Names a destination per agent, so no two parallel agents share a file: `production/releases/release-plan-[version].md`, `release-checklist-[version].md`, `qa-gate-[version].md`, `build-[version].md`, `security-signoff-[version].md`, `netcode-signoff-[version].md`, `localization-signoff-[version].md`, `performance-signoff-[version].md`, `analytics-signoff-[version].md`, `go-no-go-[version].md`, `announcement-[version].md`, `release-report-[version].md`, and `docs/patch-notes/[version].md`
+- [ ] Error Recovery Protocol section is present: verify a named artifact is on disk, surface BLOCKED immediately, always produce a partial report, full procedure (surface / assess / offer options / partial report) in `.claude/docs/error-recovery-protocol.md`
+- [ ] Phase 0 resolves `project.stage`, and a stage check before Phase 1 stops when it is not `Release` ("run `/gate-check release` first"), spawning nothing; the only way past it is an explicit `AskUserQuestion` override, asked in every `automation` mode and recorded as a `Stage override:` line in the go/no-go record and the final report
+- [ ] Has a next-step handoff referencing post-release monitoring and `/retrospective`; the skill does not write `project.stage` or `production/stage.txt` itself
+- [ ] qa-lead checks open bugs at the release gate's thresholds for the resolved `workflow`: S1 at every tier, S2 and S3 too at `full`
+- [ ] A "phase gate" is a decision point the pipeline itself lists, whatever the `automation` mode; no clause says directors spawn at phase gates
+- [ ] Phase 2 is trunk-based: the release candidate is a commit on `main`, and a `release/*` branch is cut only when the release needs stabilising (freeze / certification), with every fix also landing on `main`
+- [ ] `/patch-notes` is run by release-manager in Phase 6, and community-manager writes the announcement from its output
 - [ ] Uses `AskUserQuestion` at phase transitions requiring user approval before proceeding
+- [ ] Phase 0 resolves `team.size`, and the skill requires a one-line active-set announcement before Phase 1
 - [ ] Phase 3 agents (qa-lead, devops-engineer, and optionally security-engineer, network-programmer) are explicitly stated to run in parallel
-- [ ] Phase 6 (Deployment) is conditional on a GO decision from Phase 5
-- [ ] security-engineer is described as conditional on online features / player data — not always spawned
+- [ ] Phase 6 (Deployment) is conditional on a GO decision from Phase 5 and on an explicit `AskUserQuestion` approval regardless of `modes.automation`
+- [ ] security-engineer is described as conditional on `platform.online` / `platform.multiplayer` and player data — not always spawned, and an absent key is asked about rather than read as `false`
 
 ---
 
@@ -33,34 +50,41 @@ NO-GO. Closes with a post-release monitoring plan.
 ### Case 1: Happy Path (Single-Player) — All phases complete, version deployed
 
 **Fixture:**
-- `production/stage.txt` exists and contains a Production-or-later stage
+- Resolved config block: `review_mode: full`, `team.size: studio`, `automation: collaborative`
+- `project.stage` in `project.yaml` is `Release` (`/gate-check release` has passed)
 - Milestone acceptance criteria are all met (producer can confirm)
-- No online features, no multiplayer, no player data collection
-- All CI builds are clean on the current branch
-- No open S1/S2 bugs
-- `production/sprints/` contains the completed sprint stories for this milestone
+- `project.yaml` sets `platform.online: false` and `platform.multiplayer: false`; the game collects no player data
+- No freeze or platform certification is planned for this release
+- All CI builds are clean on `main`
+- No open S1/S2 bugs; all strings translated
 
 **Input:** `/team-release v1.0.0`
 
 **Expected behavior:**
-1. Phase 1: Spawns `producer` via Task; confirms all milestone acceptance criteria met; identifies any deferred scope; produces release authorization; presents to user; AskUserQuestion: user approves before Phase 2
-2. Phase 2: Spawns `release-manager` via Task; cuts release branch from agreed commit; bumps version numbers; invokes `/release-checklist`; freezes branch; output: branch name and checklist; AskUserQuestion: user approves before Phase 3
-3. Phase 3 (parallel): Issues Task calls simultaneously for `qa-lead` (regression suite, critical path sign-off) and `devops-engineer` (build artifacts, CI verification); security-engineer is NOT spawned (no online features); network-programmer is NOT spawned (no multiplayer); both complete successfully
-4. Phase 4: Verifies localization strings all translated; `analytics-engineer` verifies telemetry fires correctly on the release build; performance benchmarks pass; sign-off produced
-5. Phase 5: Spawns `producer` via Task; collects sign-offs from qa-lead, release-manager, devops-engineer; no open blocking issues; producer declares GO; AskUserQuestion: user sees GO decision and confirms deployment
-6. Phase 6: Spawns `release-manager` + `devops-engineer` (parallel); tags release in version control; invokes `/changelog`; deploys to staging; smoke test passes; deploys to production; simultaneously spawns `community-manager` to finalize patch notes via `/patch-notes v1.0.0` and prepare launch announcement
-7. Phase 7: release-manager generates release report; producer updates milestone tracking; qa-lead begins monitoring for regressions; community-manager publishes communication; analytics-engineer confirms live dashboards healthy
-8. Verdict: COMPLETE — release executed and deployed
+1. The stage check passes (`project.stage: Release`); before any spawn, one line announces the active set for `team.size: studio`
+2. Phase 1: Spawns `producer` via Agent; confirms all milestone acceptance criteria met; identifies any deferred scope; writes `production/releases/release-plan-v1.0.0.md`; AskUserQuestion: user approves before Phase 2
+3. Phase 2: Spawns `release-manager` via Agent; bumps version numbers on `main`, and that commit is the release candidate; finds no release checklist from Polish, so invokes `/release-checklist` (`production/releases/release-checklist-v1.0.0.md`); cuts no `release/*` branch, since nothing needs stabilising; AskUserQuestion: user approves before Phase 3
+4. Phase 3 (parallel): Issues Agent calls simultaneously for `qa-lead` (regression suite, critical path sign-off, `production/releases/qa-gate-v1.0.0.md`) and `devops-engineer` (build artifacts, CI verification, `production/releases/build-v1.0.0.md`); security-engineer is NOT spawned (`platform.online: false`, no player data) and network-programmer is NOT spawned (`platform.multiplayer: false`), and the Phase 3 output names each skip with its reason
+5. Phase 4: localization-lead verifies all strings are translated (`production/releases/localization-signoff-v1.0.0.md`); performance-analyst benchmarks the release build (`performance-signoff-v1.0.0.md`); `analytics-engineer` verifies telemetry fires correctly on the release build (`analytics-signoff-v1.0.0.md`) — each agent writes its own file
+6. Phase 5: Spawns `producer` via Agent; collects sign-offs from qa-lead, release-manager, devops-engineer and technical-director; no open blocking issues; producer declares GO (`production/releases/go-no-go-v1.0.0.md`)
+7. Phase 6: `AskUserQuestion` "Producer verdict is GO. Execute Phase 6 — tag, deploy to staging, deploy to production?" with [A] Yes, deploy / [B] Staging only — hold production / [C] Stop here; user selects [A]
+8. Phase 6: release-manager + devops-engineer tag the release, finalize the changelog via `/changelog`, deploy to staging, then production; in parallel release-manager finalizes patch notes via `/patch-notes v1.0.0` (`docs/patch-notes/v1.0.0.md`), and `community-manager` writes the launch announcement from them (`production/releases/announcement-v1.0.0.md`)
+9. Phase 7: release-manager generates the release report (`production/releases/release-report-v1.0.0.md`); producer updates milestone tracking; qa-lead monitors for regressions; community-manager publishes; analytics-engineer confirms live dashboards healthy
+10. Next steps: monitor dashboards for 48 hours; `/retrospective` if significant issues occurred
+11. Verdict: COMPLETE — release executed and deployed
 
 **Assertions:**
-- [ ] Phase 3 qa-lead and devops-engineer Task calls are issued simultaneously, not sequentially
-- [ ] security-engineer is NOT spawned when the game has no online features, multiplayer, or player data
-- [ ] Phase 5 producer collects sign-offs from all required parties before declaring GO
-- [ ] Phase 6 deployment only begins after GO decision is confirmed by the user
+- [ ] Active-set line naming `team.size: studio` appears before the first agent is spawned
+- [ ] Phase 2 cuts no `release/*` branch: the release candidate is the version-bump commit on `main`
+- [ ] Phase 3 qa-lead and devops-engineer Agent calls are issued simultaneously, not sequentially
+- [ ] security-engineer is NOT spawned when `platform.online` and `platform.multiplayer` are false and there is no player data, and the Phase 3 output says so by name (e.g. `security-engineer: not spawned — platform.online: false, platform.multiplayer: false, no player data`) — the skip is never silent
+- [ ] Each agent is told its own named output file — parallel Phase 3 and Phase 4 agents never share one — and the orchestrator confirms the file exists before treating the phase as done
+- [ ] Phase 5 producer collects sign-offs from qa-lead, release-manager, devops-engineer and technical-director before declaring GO
+- [ ] Phase 6 deployment only begins after the user picks [A] in the Phase 6 `AskUserQuestion`
 - [ ] `/changelog` is invoked by release-manager in Phase 6 (not written directly)
-- [ ] `/patch-notes v1.0.0` is invoked by community-manager in Phase 6
+- [ ] `/patch-notes v1.0.0` is invoked by release-manager in Phase 6, and community-manager writes the announcement from its output — community-manager is never asked to run `/patch-notes`
 - [ ] Phase 7 monitoring plan includes a 48-hour post-release monitoring commitment
-- [ ] Next steps recommend updating `production/stage.txt` to `Live` after successful deployment
+- [ ] No stop and no override question at the stage check, because `project.stage` reads `Release`; the skill writes neither `project.stage` nor `production/stage.txt`, and no post-launch stage value is invented
 - [ ] Verdict: COMPLETE appears in the final output
 
 ---
@@ -68,99 +92,102 @@ NO-GO. Closes with a post-release monitoring plan.
 ### Case 2: Go/No-Go: NO — S1 bug found in Phase 3, deployment skipped
 
 **Fixture:**
-- Release candidate branch exists for v0.9.0
+- Resolved config block: `team.size: small`, `automation: collaborative`, `project.stage: Release`
+- The v0.9.0 release candidate is a commit on `main`
 - qa-lead discovers a previously unreported S1 crash in the main menu during Phase 3 regression testing
 - devops-engineer build is clean and artifacts are ready
-- producer is aware of the S1 bug
 
 **Input:** `/team-release v0.9.0`
 
 **Expected behavior:**
-1. Phases 1–2 complete normally; release candidate is cut
+1. Phases 1–2 complete normally; the release candidate commit is identified
 2. Phase 3 (parallel): devops-engineer returns clean build sign-off; qa-lead returns with an S1 bug identified and regression suite failing; qa-lead declares quality gate: NOT PASSED
-3. Orchestrator surfaces the qa-lead result immediately: "QA-LEAD: S1 bug found — [crash description]. Quality gate: NOT PASSED."
-4. Phase 4 proceeds cautiously or is paused (AskUserQuestion: continue to Phase 4 or skip to Phase 5 for go/no-go?)
-5. Phase 5: Spawns `producer` via Task; producer receives qa-lead's NOT PASSED verdict; no S1 sign-off available; producer declares NO-GO with rationale: "S1 bug [ID] is open and unresolved. Releasing is not safe."
-6. AskUserQuestion: user is presented with the NO-GO decision and the S1 bug details; options: fix the bug and re-run, defer the release, or override (with documented rationale)
-7. Phase 6 (Deployment) is SKIPPED entirely — no branch tagging, no deploy to staging, no deploy to production
-8. community-manager is NOT spawned in Phase 6 (no deployment to announce)
-9. Skill ends with a partial report summarizing what was completed (Phases 1–5) and what was skipped (Phase 6) and why
-10. Verdict: BLOCKED — release not deployed
+3. At the Phase 3 → 4 transition the orchestrator writes qa-lead's full result in conversation — "QA-LEAD: S1 bug found — [crash description]. Quality gate: NOT PASSED." — and captures the decision via `AskUserQuestion`
+4. Phase 5: Spawns `producer` via Agent; producer receives qa-lead's NOT PASSED verdict; producer declares NO-GO with rationale: "S1 bug [ID] is open and unresolved. Releasing is not safe."
+5. Orchestrator surfaces "PRODUCER: NO-GO — [rationale]" and uses `AskUserQuestion` with options: fix the blocker and re-run the affected phase, defer the release, or override NO-GO with documented rationale
+6. Phase 6 (Deployment) is SKIPPED entirely — no tagging, no deploy to staging, no deploy to production
+7. Neither Phase 6 copy step runs — release-manager does not run `/patch-notes` and community-manager is NOT spawned (no deployment to announce)
+8. Skill ends with a partial report summarizing what was completed (Phases 1–5) and what was skipped (Phase 6) and why
+9. Verdict: BLOCKED — release not deployed
 
 **Assertions:**
 - [ ] qa-lead S1 bug finding is surfaced to the user immediately after Phase 3 completes — not suppressed until Phase 5
 - [ ] producer's NO-GO decision explicitly references the S1 bug and the quality gate result
 - [ ] Phase 6 Deployment is completely skipped when producer declares NO-GO
-- [ ] community-manager is NOT spawned for patch notes or launch announcement on NO-GO
+- [ ] No patch notes or launch announcement are produced on NO-GO — `/patch-notes` is not run and community-manager is NOT spawned
 - [ ] The partial report clearly states which phases completed and which were skipped, with reasons
 - [ ] Verdict: BLOCKED (not COMPLETE) when deployment is skipped due to NO-GO
 - [ ] AskUserQuestion offers the user resolution options (fix and re-run / defer / override with rationale)
-- [ ] Override path (if chosen) requires user to provide a documented rationale before proceeding to Phase 6
+- [ ] Override path (if chosen) asks for a written justification and embeds it as an "Override Justification" field in the record before any Phase 6 action
 
 ---
 
 ### Case 3: Security Audit for Online Game — security-engineer is spawned in Phase 3
 
 **Fixture:**
-- Game has multiplayer features and stores player account data
+- Resolved config block: `review_mode: full`, `team.size: studio`, `automation: collaborative`, `project.stage: Release`
+- `project.yaml` sets `platform.multiplayer: true` and `platform.online: true`; the game stores player account data
 - Release candidate exists for v2.1.0
 - qa-lead and devops-engineer both return clean sign-offs
-- security-engineer audit is required per team composition rules
 
 **Input:** `/team-release v2.1.0`
 
 **Expected behavior:**
 1. Phases 1–2 complete normally
-2. Phase 3 (parallel): Orchestrator detects that the game has online/multiplayer features and player data; issues Task calls simultaneously for `qa-lead`, `devops-engineer`, AND `security-engineer`; also spawns `network-programmer` for netcode stability sign-off
+2. Phase 3 (parallel): Orchestrator reads `platform.multiplayer: true` and `platform.online: true` from `project.yaml` and notes the stored player data; issues Agent calls simultaneously for `qa-lead`, `devops-engineer`, `security-engineer` and `network-programmer`
 3. security-engineer conducts pre-release security audit: reviews authentication flows, anti-cheat presence, data privacy compliance; returns sign-off
 4. network-programmer verifies lag compensation, reconnect handling, and bandwidth under load; returns sign-off
 5. All four Phase 3 agents complete; their results are collected before Phase 4 begins
-6. Phase 5: producer collects sign-offs from all four Phase 3 agents (qa-lead, devops-engineer, security-engineer, network-programmer) before making the go/no-go call
+6. Phase 5: producer collects sign-offs from qa-lead, release-manager, devops-engineer, security-engineer, network-programmer and technical-director before making the go/no-go call
 7. Remaining phases proceed normally to COMPLETE
 
 **Assertions:**
 - [ ] security-engineer IS spawned in Phase 3 when the game has online features, multiplayer, or player data — this is not skipped
 - [ ] network-programmer IS spawned in Phase 3 when the game has multiplayer
-- [ ] All four Phase 3 Task calls (qa-lead, devops-engineer, security-engineer, network-programmer) are issued simultaneously
+- [ ] All four Phase 3 Agent calls (qa-lead, devops-engineer, security-engineer, network-programmer) are issued simultaneously
 - [ ] security-engineer audit covers authentication, anti-cheat, and data privacy compliance
-- [ ] Phase 5 producer sign-off collection includes security-engineer (four parties, not two)
+- [ ] Phase 5 producer sign-off collection includes security-engineer and network-programmer alongside qa-lead, release-manager, devops-engineer and technical-director
 - [ ] Phase 6 deployment does not begin until security-engineer has signed off
 - [ ] Skill does NOT treat security-engineer as optional for a game with player data
 
 ---
 
-### Case 4: Localization Miss — Untranslated strings block the ship
+### Case 4: Localization Miss — Untranslated strings reach the go/no-go call
 
 **Fixture:**
+- Resolved config block: `team.size: studio`, `automation: collaborative`, `project.stage: Release`
+- `project.yaml` sets `platform.online: false` and `platform.multiplayer: false`; no player data
 - Release candidate exists for v1.2.0
 - Phase 3 (qa-lead, devops-engineer) complete with clean sign-offs
-- Phase 4: localization verification detects 47 untranslated strings in the French locale (a supported language in the game's localization scope)
-- localization-lead is available as a delegatable agent
+- Phase 4: localization-lead finds 47 untranslated strings in the French locale (a supported language) and returns it as a BLOCKED/CONCERNS item
+- producer judges the miss release-blocking and declares NO-GO
 
 **Input:** `/team-release v1.2.0`
 
 **Expected behavior:**
 1. Phases 1–3 complete with clean sign-offs
-2. Phase 4: Localization verification step detects untranslated strings; identifies 47 strings in French locale; localization-lead (if available) is spawned to assess the severity
-3. Orchestrator surfaces: "LOCALIZATION MISS: 47 untranslated strings found in French locale. Localization sign-off is required before shipping."
-4. AskUserQuestion: options presented — (a) Fix translations and re-run Phase 4, (b) Remove French locale from this release, (c) Ship as-is with a known issues note
-5. If user selects (a): Phase 4 is re-run after translations are provided; skill waits for localization sign-off
-6. Phase 5 go/no-go does NOT proceed while localization sign-off is outstanding
-7. Ship is blocked (Phase 6 not entered) until localization issue is resolved or explicitly waived
+2. Phase 4: the translation check is delegated to localization-lead (active at `studio`); its sign-off is written to `production/releases/localization-signoff-v1.2.0.md` and the orchestrator confirms the file exists
+3. At the Phase 4 → 5 transition the orchestrator writes the localization finding in conversation and captures the decision via `AskUserQuestion` — it does not auto-advance
+4. Phase 5: producer evaluates the untranslated strings as an open issue and declares NO-GO
+5. Orchestrator surfaces "PRODUCER: NO-GO — [rationale naming the untranslated French strings]" and offers via `AskUserQuestion`: fix the blocker and re-run the affected phase / defer the release / override NO-GO with documented rationale
+6. Phase 6 is skipped entirely; a partial report lists Phases 1–5 as completed and Phase 6 as skipped with the reason
+7. Verdict: BLOCKED — release not deployed
 
 **Assertions:**
-- [ ] Localization verification in Phase 4 detects untranslated strings and counts them (not just "some strings missing")
-- [ ] Untranslated strings for a supported locale block the pipeline before Phase 5
-- [ ] AskUserQuestion is used to offer the user resolution choices — the skill does not auto-waive
-- [ ] Phase 5 go/no-go is NOT called while localization sign-off is pending
-- [ ] If user chooses to re-run Phase 4: the skill does not require restarting from Phase 1
-- [ ] If user explicitly waives (ships as-is): the waiver is documented in the release report (Phase 7) as a known issue
-- [ ] Skill does NOT fabricate translated strings to unblock itself
+- [ ] Phase 4 delegates the translation check to localization-lead when it is in the active set
+- [ ] The localization finding is presented at the Phase 4 → 5 transition via `AskUserQuestion` before the go/no-go runs
+- [ ] The producer's NO-GO rationale names the untranslated-strings issue
+- [ ] The resolution options include re-running the affected phase — the skill does not require restarting from Phase 1
+- [ ] If the user overrides, the written justification is embedded in the record before any Phase 6 action
+- [ ] The orchestrator writes no files itself — it does not produce translations to unblock the release
+- [ ] Verdict is BLOCKED and Phase 6 does not run on NO-GO
 
 ---
 
 ### Case 5: No Argument — Skill infers version or asks
 
+In both variants `project.stage` is `Release`.
+
 **Fixture (variant A — milestone data present):**
 - `production/milestones/` exists with a milestone file; most recent milestone is "v1.1.0 — Gold"
 - `production/session-state/active.md` references a version or milestone
@@ -173,13 +200,13 @@ NO-GO. Closes with a post-release monitoring plan.
 **Input:** `/team-release` (no argument)
 
 **Expected behavior (variant A):**
-1. Phase 1: No argument provided; reads `production/session-state/active.md`; reads most recent milestone file in `production/milestones/`
+1. Argument check: no version provided; reads `production/session-state/active.md` and the most recent milestone file in `production/milestones/`
 2. Infers v1.1.0 as the target version; reports "No version argument provided — inferred v1.1.0 from milestone data. Proceeding."
-3. Confirms with AskUserQuestion before beginning Phase 1 proper: "Releasing v1.1.0. Is this correct?"
+3. Confirms with AskUserQuestion before beginning Phase 1: "Releasing v1.1.0. Is this correct?"
 4. Proceeds as if `/team-release v1.1.0` was the input
 
 **Expected behavior (variant B):**
-1. Phase 1: No argument provided; reads available state files — no version discoverable
+1. Argument check: no version provided; reads available state files — no version discoverable
 2. Uses AskUserQuestion: "What version number should be released? (e.g., v1.0.0)"
 3. Waits for user input before proceeding
 
@@ -192,24 +219,61 @@ NO-GO. Closes with a post-release monitoring plan.
 
 ---
 
+### Case 6: Stage Still Polish — Stops Before Phase 1, Nothing Spawned
+
+**Fixture:**
+- Resolved config block: `review_mode: full`, `team.size: studio`, `automation: autonomous`, `project.stage: Polish`
+- `/gate-check release` has not been run; a release candidate exists for v1.0.0
+
+**Input:** `/team-release v1.0.0`
+
+**Expected behavior (variant A — the user stops):**
+1. Phase 0 resolves `project.stage: Polish`; the stage check stops before Phase 1: "The release readiness gate has not passed (project.stage: Polish) — run `/gate-check release` first."
+2. `AskUserQuestion` offers `[A] Stop — I'll run /gate-check release (recommended)` / `[B] Proceed anyway — override the stage check` — asked even though `automation` is `autonomous`
+3. User picks `[A]`: no agent is spawned, no file is written, nothing is tagged or deployed
+4. Verdict: BLOCKED — release gate not passed
+
+**Expected behavior (variant B — the user overrides):**
+1. Same stop and question; user picks `[B]` and, asked why, answers "cert window closes Friday"
+2. The run continues to Phase 1 with the override in the producer's brief
+3. The go/no-go record (`production/releases/go-no-go-v1.0.0.md`) and the final report carry `Stage override: project.stage was Polish — release gate not passed; the user chose to proceed: cert window closes Friday`
+4. `project.stage` still reads `Polish` at the end of the run
+
+**Assertions:**
+- [ ] No `Agent` call is issued before the stage-check question is answered
+- [ ] The stop message names `/gate-check release` as the step to run first
+- [ ] The question is asked in `autonomous` mode — the override is never taken automatically
+- [ ] On `[A]` the verdict is BLOCKED and no agent is spawned at all (not even release-manager)
+- [ ] On `[B]` the override and its reason appear in the go/no-go record and in the final report
+- [ ] The skill writes neither `project.stage` nor `production/stage.txt` in either variant
+
+---
+
 ## Protocol Compliance
 
-- [ ] `AskUserQuestion` used at each phase transition gate (post-Phase 1, post-Phase 2, post-Phase 3/4 if issues, post-Phase 5 go/no-go)
-- [ ] Phase 3 agents are always issued as parallel Task calls — qa-lead and devops-engineer are never sequential
-- [ ] security-engineer is conditionally spawned based on game features — never silently skipped when features are present
-- [ ] File Write Protocol: orchestrator never calls Write/Edit directly — all writes are delegated to sub-agents or sub-skills
-- [ ] Phase 6 Deployment is strictly conditional on a GO verdict from Phase 5 — never auto-triggered
+- [ ] At the default `team.size: individual`, the run opens with `Active set (team.size: individual): release-manager.` and a `Not spawned this run:` line naming every other agent the pipeline names, consulted through release-manager — before any agent is spawned
+- [ ] In `collaborative` mode, `AskUserQuestion` used at each phase transition gate (post-Phase 1, post-Phase 2, post-Phase 3, post-Phase 4, post-Phase 5 go/no-go)
+- [ ] Phase 3 agents in the active set are always issued as parallel Agent calls — qa-lead and devops-engineer are never sequential
+- [ ] security-engineer is conditionally spawned from `platform.online` / `platform.multiplayer` and player data — never silently skipped: an absent key is asked about, and a skip is named in the Phase 3 output
+- [ ] At `review_mode: lean` or `solo`, technical-director is not spawned for the Phase 5 sign-off, and the go/no-go record says `technical-director sign-off: not run (review_mode: <mode>)` rather than listing it as given
+- [ ] A technical-director `NOT ASSESSED [missing input]` answer is recorded as such in the go/no-go record and never counted as a sign-off
+- [ ] When a `release/*` branch is cut to stabilise a release, it takes bug fixes only and every fix also lands on `main`
+- [ ] File Write Protocol: orchestrator never calls Write/Edit directly — sub-agents write their named paths under the bounded exception, sub-skills ask before writing
+- [ ] Phase 6 Deployment is strictly conditional on a GO verdict from Phase 5 and an explicit `AskUserQuestion` approval — never auto-triggered, including in `autonomous` mode
 - [ ] Error recovery: any BLOCKED agent is surfaced immediately before continuing to dependent phases
-- [ ] Partial reports are always produced if any phase fails or the pipeline is halted (Case 2)
-- [ ] Verdict: COMPLETE only when deployment completes; BLOCKED when go/no-go is NO or a hard blocker is unresolved
-- [ ] Next steps always include 48-hour post-release monitoring, `/retrospective` recommendation, and `production/stage.txt` update to `Live`
+- [ ] A phase whose named artifact is missing on disk is treated as failed, not done
+- [ ] Partial reports are always produced if any phase fails or the pipeline is halted (Cases 2 and 4)
+- [ ] Verdict: COMPLETE only when deployment completes; BLOCKED when the stage check stops the run, go/no-go is NO, or a hard blocker is unresolved
+- [ ] Stage check: when `project.stage` is not `Release`, nothing is spawned until the user answers the stop question; proceeding takes the explicit `[B]` override, which is recorded (Case 6)
+- [ ] Next steps always include 48-hour post-release monitoring and a `/retrospective` recommendation — never a direct `project.stage` write
 
 ---
 
 ## Coverage Notes
 
 - Phase 7 post-release actions (release report, milestone tracking, community publishing, dashboard monitoring) are validated implicitly by Case 1. No separate edge case is required as Phase 7 is non-gated and does not have a blocking failure mode.
-- The "devops-engineer build fails" path is not separately tested — it would surface as a BLOCKED result in Phase 3 and follow the standard error recovery protocol (surface → assess → AskUserQuestion options). This is validated structurally by the Static Assertions error recovery check.
-- The parallel Phase 4 path (localization + performance + analytics simultaneously with Phase 3) is a documented option in the skill ("can run in parallel with Phase 3 if resources available"). Case 4 tests Phase 4 as a sequential gate; the parallel variant is left to the skill's implementation judgment.
-- The `network-programmer` sign-off path for multiplayer is validated as part of Case 3 rather than a separate case, as it follows the same parallel-spawn pattern as security-engineer.
-- The "override NO-GO with documented rationale" path in Case 2 is referenced but not exhaustively tested — it is an escape hatch that the skill must support, and its existence is validated by the AskUserQuestion options assertion in Case 2.
+- The "devops-engineer build fails" path is not separately tested — it would surface as a BLOCKED result in Phase 3 and follow the standard error recovery protocol (surface → assess → AskUserQuestion options).
+- The parallel Phase 4 path (running alongside Phase 3 "if resources available") is left to the skill's judgment; Case 4 tests Phase 4 as a sequential phase.
+- The `[B] Staging only — hold production` Phase 6 option is not separately tested.
+- A release that needs stabilising (a freeze or platform certification, so a `release/*` branch is cut) is not given its own case; the rule is asserted in Protocol Compliance.
+- The "override NO-GO with documented rationale" path is checked for its justification step in Cases 2 and 4 but not followed through a full deployment.