Release 1.1.0 — one config file, and a process weight you choose

`project.yaml` at the repo root is now the single source of truth for a
project's configuration, replacing `production/stage.txt`,
`production/review-mode.txt` and `.claude/docs/technical-preferences.md` (all
three still read as a fallback; nothing is force-deleted).

**`modes.rigor` — one question instead of six.** `minimal`, `standard` or
`full` fronts six knobs: `modes.workflow`, `docs.density`, `qa.level`,
`modes.story_granularity`, `modes.review_mode` and `team.size`. It defaults to
`minimal`, which is a change from 1.0's behaviour: the heavier tier was
measured costing several times more to reach working code without producing a
better result, and returning nothing when a fresh developer inherited the
project. Pin `modes.rigor: standard` to keep 1.0's process level.

Also in this release:

- `/settings` to view or change any setting, and `project.local.yaml` for
  per-developer preferences that should not be committed.
- `system_overrides` to hold one system to a higher standard than the rest of
  the project, and `testing.strict` to set per test type whether missing
  evidence blocks a story or warns.
- A story that changes anything the player sees is not closed until the game
  has been launched, observed, and a screenshot retained in
  `production/qa/evidence/`. A parse check is not a run. This holds at every
  rigor level, including `minimal`, where automated tests are waived but the
  look is not.
- The code root is engine-specific and enforced as such: Godot `src/`, Unity
  `Assets/`, Unreal `Source/<Module>/`. Two of the three will not build a
  project laid out any other way.
- Migration tooling for existing projects: `.claude/scripts/migrate-v1-config.sh`
  converts a 1.0 layout, non-destructively by default, with a report to review
  before `--finalize` deletes anything.
- Ask-before-write holds regardless of personal automation settings.

Upgrading from 1.0 or earlier: see UPGRADING.md. Full list of changes:
CHANGELOG.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016xvzG3i7pWQg4LjyDwWMXd

.claude/skills/release-checklist/SKILL.md

@@ -1,11 +1,60 @@
 ---
 name: release-checklist
-description: "Generates a comprehensive pre-release validation checklist covering build verification, certification requirements, store metadata, and launch readiness."
+description: "Pre-release checklist — build verification, certification requirements, store metadata, launch readiness."
 argument-hint: "[platform: pc|console|mobile|all]"
 user-invocable: true
 allowed-tools: Read, Glob, Grep, Write
 model: sonnet
 ---
+!`source "${CLAUDE_PROJECT_DIR:-.}/.claude/hooks/yaml-helper.sh" 2>/dev/null && resolve_config --keys rigor,project.stage,cert_tier,automation`
+
+**Automation mode**: Resolve `modes.automation` (`project.local.yaml` →
+`project.yaml` → default `collaborative`). Every `AskUserQuestion` call and
+every file write follows `.claude/docs/automation-modes.md`
+(collaborative asks always · guided major-only · autonomous logs and proceeds;
+`automation_always_ask` categories always prompt).
+
+Resolved above — use as-is. No block → defaults in `.claude/docs/config-resolution.md`.
+
+**Scope this checklist to the project.** Emitting every item for every platform
+trains the reader to skip the list, which defeats the gate:
+
+- **`project.stage`** — items for phases this project has not reached are out of
+  scope; say so rather than listing them unchecked.
+- **`modes.rigor`** — at `minimal`, drop items whose only justification is process
+  weight this project has opted out of.
+- **`platform.cert_tier`** — emit certification items **only** for the tier the
+  project targets. If it is **unset**, **ask which platforms are in scope**
+  rather than emitting all of them — an unset value is a question, not a licence
+  to emit every certification track. If it cannot be determined, mark the section
+  **`NOT ASSESSED — cert tier unknown`**. **Unset is not `none`:** `none` is a
+  decision, unset is a missing one, and they must not produce the same output.
+  Branch on the **four values this key takes** — `none | itch | steam | console` —
+  and not on platform names; `.claude/docs/effects-map.md` holds the full
+  requirement table and is the source, so read it rather than restating it.
+  - `none` — **emit no certification section at all.** Internal release, alpha or
+    jam game. Say the section was omitted and why; do not leave it blank.
+  - `itch` — itch.io upload requirements only: build size, page setup, age tags.
+    **No console and no Steamworks items.**
+  - `steam` — Steamworks: store page, depot build, achievements, system
+    requirements, common content rules. **No console certification items.**
+  - `console` — full platform certification (TRC / XR / Lotcheck), save-data
+    rules, controller-mapping rules, age-rating boards. The heaviest tier.
+
+  > **Branch on the `cert_tier` values above, not on platform names.** "Emit
+  > console/mobile certification items only for the platforms the project targets"
+  > is the wrong test: it treats an `itch` project and a `steam` project
+  > identically, conflates `none` with unset, and keys on `mobile`, which is not a
+  > `cert_tier` value at all. Use the vocabulary the config defines.
+
+If an item cannot be scoped because the config is absent, mark it
+**`NOT ASSESSED — platform/stage unknown`**. Do not silently include it: a
+`rigor: standard`, single-platform project would otherwise receive a ~150-item
+checklist demanding PC **and** console **and** mobile certification plus age
+ratings, of which ~140 are unassessable.
+
+---
+
 
 > **Explicit invocation only**: This skill should only run when the user explicitly requests it with `/release-checklist`. Do not auto-invoke based on context matching.
 
@@ -13,6 +62,16 @@ model: sonnet
 
 Read the argument for the target platform (`pc`, `console`, `mobile`, or `all`). If no platform is specified, default to `all`.
 
+**The argument selects DEVICE requirements. It never selects the certification
+track.** Certification is decided by `platform.cert_tier`, resolved in the resolved-config block at the top of this skill —
+see the `platform.cert_tier` rule above. The two axes are different lists that
+happen to share one word: `pc`/`console`/`mobile` are hardware shapes, while
+`none|itch|steam|console` are certification regimes. They agree on `console` and
+nowhere else — `itch` and `none` have no device block at all, and `mobile` is not
+a `cert_tier` value. So emitting a device block says nothing about which
+certification block to emit, and `all` is **not** a licence to emit every
+certification track.
+
 ---
 
 ## Phase 2: Load Project Context
@@ -24,6 +83,17 @@ Read the argument for the target platform (`pc`, `console`, `mobile`, or `all`).
 
 ## Phase 3: Scan Codebase
 
+> **State the denominator with every count.** These scans look for something bad,
+> so `0` means either "searched and found none" or "there was nothing to search",
+> and on a release gate those are opposite findings. Report
+> `scanned [N] source files: [M] TODO, [M] FIXME, [M] HACK` — or, when `src/` is
+> absent or holds no source files,
+> **`NOT ASSESSED — no source files found to scan`**. A bare `0` is not a result.
+>
+> `/launch-checklist` scans the same way and is most often run beside this one.
+> Keep the two consistent: changing the rule in one and not the other leaves a
+> route to the same misleading `0`.
+
 Scan for outstanding issues:
 
 - Count `TODO` comments
@@ -32,6 +102,9 @@ Scan for outstanding issues:
 - Note their locations and severity
 
 Check for test results in any test output directories or CI logs if available.
+**If none are found, say so** — `Test results: NOT ASSESSED — no test output or
+CI logs found` — rather than omitting the line. An absent test result and a
+passing one must not produce the same release checklist.
 
 ---
 
@@ -75,7 +148,10 @@ Generated: [Date]
 - [ ] Credits complete and accurate
 ```
 
-Add platform-specific sections based on the argument:
+Add **device** sections based on the argument. These carry no certification or
+storefront-SDK items — those are gated on `platform.cert_tier` in the next
+subsection, and duplicating them here is what let an `itch` project receive
+Steamworks rows.
 
 **For `pc`:**
 ```markdown
@@ -86,24 +162,16 @@ Add platform-specific sections based on the argument:
 - [ ] Resolution scaling tested (1080p, 1440p, 4K, ultrawide)
 - [ ] Windowed, borderless, and fullscreen modes working
 - [ ] Graphics settings save and load correctly
-- [ ] Steam/Epic/GOG SDK integrated and tested
-- [ ] Achievements functional
-- [ ] Cloud saves functional
-- [ ] Steam Deck compatibility verified (if targeting)
 ```
 
 **For `console`:**
 ```markdown
 ### Platform Requirements: Console
-- [ ] TRC/TCR/Lotcheck requirements checklist complete
 - [ ] Platform-specific controller prompts display correctly
 - [ ] Suspend/resume works correctly
 - [ ] User switching handled properly
 - [ ] Network connectivity loss handled gracefully
 - [ ] Storage full scenario handled
-- [ ] Parental controls respected
-- [ ] Platform-specific achievement/trophy integration tested
-- [ ] First-party certification submission prepared
 ```
 
 **For `mobile`:**
@@ -121,6 +189,71 @@ Add platform-specific sections based on the argument:
 - [ ] App size within store limits
 ```
 
+> **Mobile storefront rows stay here on purpose.** `platform.cert_tier` models
+> `none|itch|steam|console` and has no mobile regime, so App Store / Play Store
+> compliance cannot be gated on it. Leaving these in the device block is a
+> deliberate choice, not an oversight — do not "fix" it by inventing a `mobile`
+> tier, which is the exact wrong vocabulary the `cert_tier` rule warns against.
+
+**Certification — emit ONLY the block matching `platform.cert_tier`** (resolved in
+the resolved-config block at the top of this skill). Do not emit this subsection's other blocks, and do not fall back to
+emitting all of them because the platform argument was `all`.
+
+**At `none`** — emit no certification block at all. Emit exactly this one line in
+its place, so the omission is visible rather than looking like a missing section:
+```markdown
+Certification: omitted — cert_tier is 'none' (internal build, alpha or jam release).
+```
+
+**At `itch`:**
+```markdown
+### Certification: itch.io
+- [ ] Build size within itch.io upload limits
+- [ ] itch.io page complete (cover art, screenshots, description)
+- [ ] Age/content tags set honestly
+- [ ] Downloadable vs browser build decided and tested
+- [ ] Butler channel names correct for each platform uploaded
+```
+
+**At `steam`:**
+```markdown
+### Certification: Steamworks
+- [ ] Steamworks SDK integrated and tested
+- [ ] Depot build uploaded and installs cleanly from a fresh account
+- [ ] Achievements functional
+- [ ] Cloud saves functional
+- [ ] Steam Deck compatibility verified (if targeting)
+- [ ] Steam common content rules reviewed
+```
+
+**At `console`:**
+```markdown
+### Certification: Console
+- [ ] TRC/TCR/Lotcheck requirements checklist complete
+- [ ] First-party certification submission prepared
+- [ ] Platform-specific achievement/trophy integration tested
+- [ ] Parental controls respected
+- [ ] Save-data rules compliant (corruption, full storage, user switching)
+- [ ] Age ratings obtained (ESRB, PEGI, regional)
+```
+
+If `cert_tier` is **unset**, ask which platforms are in scope rather than
+emitting every track; if it cannot be determined, emit
+`### Certification: NOT ASSESSED — cert tier unknown` and say why. **Unset is not
+`none`** — `none` is a decision and unset is a missing one.
+
+> **Certification rows belong here, in one `cert_tier`-gated subsection.** Do not
+> spread them back through the PC, Console and Mobile device blocks: those are
+> selected by the command argument and default to `all`, so an `itch` project
+> running `/release-checklist` with no argument would be handed the Steamworks SDK
+> rows *and* the Lotcheck rows — exactly what the `cert_tier` rule at the top of
+> this skill forbids.
+>
+> **`console` means two different things in this file.** It is a device-block
+> argument value *and* a `cert_tier` value, colliding on one word out of four. A
+> `**For \`console\`:**` heading is argument-gating, not tier-gating — do not read
+> it as evidence that certification is already scoped by tier.
+
 **Store and launch sections (all platforms):**
 ```markdown
 ### Store / Distribution