Unity QA Release

Prove the game works as a player encounters it, then generate a shippable iOS build with its risks named. The deliverable is an Xcode project plus a release risk report — not a signed .ipa, and never a "shipped" claim without evidence.

Doctrine (these override convenience)

1. Verify with real evidence. Tests, screenshots, build output. Never say "done", "works", "passes", "built", "signed", or "shipped" without an artifact: green test results, a screenshot of the running scene, or actual build/status output. A clean read_console is not optional.
2. Lean gates, but gate release. Don't stack a prompt at every micro-step, but release IS a gate. Do not produce a release report until QA + tests + a build-or-blocker exist.
3. Edit/build through MCP, not files. All Editor work — running, testing, building — goes through unity-mcp-bridge (CoplayDev unity-mcp). Scenes/prefabs/.asset are GUID-linked YAML; never hand-edit.
4. Unity 6 build pipeline differs from default knowledge. The model's built-in knowledge is ~Unity 2022.3. Build Profiles (the profile param on manage_build) need Unity 6+. If unsure about a manage_build action/property or a player setting API, verify via MCP (unity_reflect / unity_docs, docs group) before acting — don't write from memory.

Confirm the Editor is reachable first: read mcpforunity://editor/state and proceed only when ready_for_tools==true, is_compiling==false, is_domain_reload_pending==false. If MCP/Editor is down, say so and author the steps for manual run — do not claim QA/build happened.

QA gates before release

Load references/checklists/playtest-qa.md and walk it. Gate on: