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/day-one-patch/SKILL.md

@@ -1,9 +1,10 @@
 ---
 name: day-one-patch
-description: "Prepare a day-one patch for a game launch. Scopes, prioritises, implements, and QA-gates a focused patch addressing known issues discovered after gold master but before or immediately after public launch. Treats the patch as a mini-sprint with its own QA gate and rollback plan."
+description: "Day-one launch patch — focused fix for known issues found after gold master. Mini-sprint with QA gate and rollback."
 argument-hint: "[scope: known-bugs | cert-feedback | all]"
 user-invocable: true
-allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion
+disable-model-invocation: true
+allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Agent, AskUserQuestion
 model: sonnet
 ---
 
@@ -33,15 +34,32 @@ ships. It is a mini-sprint — not a hotfix, not a full sprint.
 ## Phase 1: Load Release Context
 
 Read:
-- `production/stage.txt` — confirm project is in Release stage
+- `project.stage` in `project.yaml` (fallback `production/stage.txt`) — confirm project is in Release stage
 - The most recent file in `production/gate-checks/` — read the release gate verdict
 - `production/qa/bugs/*.md` — load all bugs with Status: Open or Fixed — Pending Verification
 - `production/sprints/` most recent — understand what shipped
 - `production/security/security-audit-*.md` most recent — check for any open security items
 
-If `production/stage.txt` is not `Release` or `Polish`:
+If the resolved stage (project.yaml → stage.txt) is not `Release` or `Polish`:
 > "Day-one patch prep is for Release-stage projects. Current stage: [stage]. This skill is not appropriate until you are approaching launch."
 
+**Check the premise, do not assume it.** This whole skill rests on there being a
+gold master that already passed a release gate — that premise is what justifies
+its lightweight QA pass instead of a full one. So verify it rather than inferring
+it from the stage value:
+
+- **No file in `production/gate-checks/`**, or none recording a release-gate
+  verdict: report `Release gate: NOT ASSESSED — no gate-check record found`. Do
+  not proceed silently. Say plainly that the reduced QA scope below is justified
+  by a gate nobody can find, and ask whether to run `/gate-check` first or
+  proceed with a full QA pass instead.
+- **The most recent record is FAIL, CONCERNS or NOT ASSESSED**: name it and stop.
+  A day-one patch on top of a build that never passed its gate is not a day-one
+  patch; it is the release gate, arriving late and scoped to the wrong changes.
+- `project.stage: Release` on its own does **not** establish this. The stage is a
+  claim about where the project is; the gate record is the evidence that it earned
+  the position.
+
 ---
 
 ## Phase 2: Scope the Patch
@@ -84,7 +102,7 @@ Use `AskUserQuestion` to confirm proceeding or reduce scope.
 
 Before any code is written, define the rollback procedure. This is non-negotiable.
 
-Spawn `release-manager` via Task. Ask them to produce a rollback plan covering:
+Spawn `release-manager` via `Agent`. Ask them to produce a rollback plan covering:
 - How to revert to the gold master build on each target platform
 - Platform-specific rollback constraints (some platforms cannot roll back cert builds)
 - Who is responsible for triggering the rollback
@@ -100,14 +118,14 @@ Do not proceed to Phase 4 until the rollback plan is written.
 
 For each bug in the approved scope, spawn a focused implementation loop:
 
-1. Spawn `lead-programmer` via Task with:
+1. Spawn `lead-programmer` via `Agent` with:
    - The bug report (exact reproduction steps and root cause if known)
    - The constraint: minimum viable fix only, no cleanup
    - The affected files (from bug report Technical Context section)
 
 2. The lead-programmer implements and runs targeted tests.
 
-3. Spawn `qa-tester` via Task to verify: does the bug reproduce after the fix?
+3. Spawn `qa-tester` via `Agent` to verify: does the bug reproduce after the fix?
 
 For config/data-only fixes: make the change directly (no programmer agent needed). Confirm the value changed and re-run any relevant smoke test.
 
@@ -117,7 +135,7 @@ For config/data-only fixes: make the change directly (no programmer agent needed
 
 This is a lightweight QA pass — not a full `/team-qa`. The patch is already QA-approved from the release gate; we are only re-verifying the changed areas.
 
-Spawn `qa-lead` via Task with:
+Spawn `qa-lead` via `Agent` with:
 - List of all changed files
 - List of bugs fixed (with verification status from Phase 4)
 - The smoke check scope for the affected systems
@@ -130,6 +148,14 @@ Run the required QA scope:
 
 QA verdict must be PASS or PASS WITH WARNINGS before proceeding. If FAIL: scope the failing fix out of the day-one patch and defer to 1.1.
 
+**If the QA verdict is `NOT ASSESSED`, that is not a pass.** `/smoke-check` returns
+it when the suite never ran — no build, no runner, or a result nobody confirmed.
+Do not proceed on it and do not re-read it as PASS WITH WARNINGS: the warnings
+value means somebody looked and saw something minor, and this means nobody looked.
+Either obtain the result (the verdict names what would make it runnable) or defer
+the fix to 1.1. A day-one patch ships to every player who buys the game on day
+one, which is the worst possible audience for an unverified change.
+
 ---
 
 ## Phase 6: Generate Patch Record
@@ -161,10 +187,11 @@ QA verdict must be PASS or PASS WITH WARNINGS before proceeding. If FAIL: scope
 ## QA Sign-Off
 
 **QA scope**: [Targeted smoke / Broader regression]
-**Verdict**: [PASS / PASS WITH WARNINGS]
+**Verdict**: [PASS / PASS WITH WARNINGS / NOT ASSESSED]
 **QA lead**: qa-lead agent
 **Date**: [date]
 **Warnings (if any)**: [list or "None"]
+**Not assessed (if any)**: [what could not be checked, and why — or "None"]
 
 ---