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/ux-review/SKILL.md

@@ -1,11 +1,10 @@
 ---
 name: ux-review
-description: "Validates a UX spec, HUD design, or interaction pattern library for completeness, accessibility compliance, GDD alignment, and implementation readiness. Produces APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED verdict with specific gaps."
+description: "Validate a UX spec, HUD design or pattern library — accessibility, GDD alignment, readiness. APPROVED / NOT ASSESSED / NEEDS REVISION / MAJOR REVISION NEEDED."
 argument-hint: "[file-path or 'all' or 'hud' or 'patterns']"
 user-invocable: true
 allowed-tools: Read, Glob, Grep
 model: sonnet
-agent: ux-designer
 ---
 
 ## Overview
@@ -23,10 +22,19 @@ the `/team-ui` pipeline.
 
 **Verdict levels:**
 - **APPROVED** — spec is complete, consistent, and implementation-ready
+- **NOT ASSESSED** — one or more review dimensions had no criterion to check
+  against, or the spec could not be read; name which
 - **NEEDS REVISION** — specific gaps found; fix before handoff but not a full redesign
 - **MAJOR REVISION NEEDED** — fundamental issues with scope, player need, or
   completeness; needs significant rework
 
+**`NOT ASSESSED` ranks above APPROVED and below the two revision verdicts.** A
+review that could not evaluate a dimension has not shown the spec is
+implementation-ready; but a gap somebody found is more actionable than one nobody
+could look for, so it must not displace them. Emit it when the spec file cannot
+be read, when a checklist dimension has no source of truth to compare against, or
+when the accessibility tier is uncommitted (below).
+
 ---
 
 ## Phase 1: Parse Arguments
@@ -47,10 +55,18 @@ full detail for each.
 
 Before validating any spec, load:
 
-1. **Input & Platform config**: Read `.claude/docs/technical-preferences.md` and
-   extract `## Input & Platform`. This is the authoritative source for which input
-   methods the game supports — use it to drive the Input Method Coverage checks in
-   Phase 3A, not the spec's own header. If unconfigured, fall back to the spec header.
+1. **Input & Platform config**: Read the `platform` block from `project.yaml`
+   (`platform.targets`, `platform.primary_input`, `platform.gamepad_support`,
+   `platform.touch_support`); if `project.yaml` has no `platform` block, fall
+   back to the `## Input & Platform` section of
+   `.claude/docs/technical-preferences.md`. For the set of supported input
+   methods: when reading from `project.yaml`, derive it — keyboard/mouse if
+   `PC` or `Web` is in `targets`; gamepad if `gamepad_support` is Full or
+   Partial; touch if `touch_support` is Full or Partial; plus `primary_input`.
+   When falling back to `technical-preferences.md`, use its explicit Input
+   Methods field instead. This is the authoritative source for the Input Method
+   Coverage checks in Phase 3A — not the spec's own header. If neither source is
+   configured, fall back to the spec header.
 2. The accessibility tier committed to in `design/accessibility-requirements.md`
    (if it exists)
 3. The interaction pattern library at `design/ux/interaction-patterns.md` (if
@@ -223,20 +239,36 @@ Run all checks against a `hud-design.md`-based document.
 - GDD [name] UI Requirements — [X/Y requirements covered]
 - Missing: [list any uncovered GDD requirements]
 
-### Accessibility: [COMPLIANT / GAPS / NON-COMPLIANT]
+### Accessibility: [COMPLIANT / GAPS / NON-COMPLIANT / NOT ASSESSED]
 - Target tier: [tier]
 - [list specific accessibility findings]
 
+> **If `design/accessibility-requirements.md` is absent there is no committed
+> tier, so this dimension has no criterion.** Report
+> `Accessibility: NOT ASSESSED — no committed tier (design/accessibility-requirements.md absent)`
+> and do NOT report it as COMPLIANT — a gate compared against an absent standard
+> passes the way an assertion that can never fail passes. The same rule lives in
+> `/team-ui` Phase 4 and is mirrored here so the two cannot drift. If the spec's own
+> header states a tier, carry it forward as an **assumption** and say plainly that
+> it was assumed rather than committed. Recommend `/ux-design accessibility` to
+> establish the tier.
+
 ### Pattern Library: [CONSISTENT / INCONSISTENCIES FOUND]
 - [findings]
 
-### Verdict: APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED
+### Verdict: APPROVED / NOT ASSESSED / NEEDS REVISION / MAJOR REVISION NEEDED
 **Blocking issues**: [N] — must be resolved before implementation
 **Advisory issues**: [N] — recommended but not blocking
+**Dimensions not assessed**: [N] — [name each, and what would make it checkable]
 
 [For APPROVED]: This spec is ready for handoff to `/team-ui` Phase 2
 (Visual Design).
 
+[For NOT ASSESSED]: [N] of the four review dimensions could not be evaluated:
+[name them]. The spec may well be sound — this review cannot say either way for
+those dimensions. [For each: the one input that would make it checkable.]
+Handoff to `/team-ui` is not recommended on this result.
+
 [For NEEDS REVISION]: Address the [N] blocking issues above, then re-run
 `/ux-review`.
 
@@ -252,6 +284,10 @@ This skill is READ-ONLY — it never edits or writes files. It reports findings
 
 After delivering the verdict:
 - For **APPROVED**: suggest running `/team-ui` to begin implementation coordination
+- For **NOT ASSESSED**: name the missing input per dimension and offer to help
+  produce it (`/ux-design accessibility` for an uncommitted tier, the GDD path
+  for absent UI requirements). Do not re-run the review against the same missing
+  inputs and report a different verdict — only new inputs change this one
 - For **NEEDS REVISION**: offer to help fix specific gaps ("Would you like me to
   help draft the missing error state?") — but do not auto-fix; wait for user
   instruction