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

design/CLAUDE.md

@@ -4,7 +4,7 @@ When authoring or editing files in this directory, follow these standards.
 
 ## GDD Files (`design/gdd/`)
 
-Every GDD must include all **8 required sections** in this order:
+The 8 GDD sections, in order:
 1. Overview — one-paragraph summary
 2. Player Fantasy — intended feeling and experience
 3. Detailed Rules — unambiguous mechanics
@@ -14,6 +14,23 @@ Every GDD must include all **8 required sections** in this order:
 7. Tuning Knobs — configurable values identified
 8. Acceptance Criteria — testable success conditions
 
+**How many are REQUIRED depends on `modes.workflow`** — all 8 at `full`; 5 at
+`standard` (Overview, Detailed Rules, Edge Cases, Dependencies, Acceptance
+Criteria, plus Formulas when the system has math); none at `minimal`, where
+`design/game-brief.md` is the design record instead of a GDD. Resolve the tier
+before flagging a section as missing — see `.claude/docs/workflow-modes.md`.
+
+> **Three other places already encode the tier rule** —
+> `.claude/docs/coding-standards.md`, `.claude/rules/design-docs.md` and
+> `.claude/hooks/validate-commit.sh`. This file is the copy a session working in
+> `design/` reads first, so it must agree with them: demanding all 8 at
+> `minimal` warns a jam project about six sections its own configuration says it
+> does not need, which trains the user to ignore the warning.
+
+**Section-name alias:** the GDD template and `/design-system` author section 3
+as `## Detailed Design`; the standard calls it **Detailed Rules**. Same required
+section — accept either heading, never rewrite one into the other.
+
 **File naming:** `[system-slug].md` (e.g. `movement-system.md`, `combat-system.md`)
 
 **Systems index:** `design/gdd/systems-index.md` — update when adding a new GDD.
@@ -33,6 +50,14 @@ Use `/quick-design` to author.
 - Per-screen specs: `design/ux/[screen-name].md`
 - HUD design: `design/ux/hud.md`
 - Interaction pattern library: `design/ux/interaction-patterns.md`
-- Accessibility requirements: `design/ux/accessibility-requirements.md`
+- Accessibility requirements: `design/accessibility-requirements.md`
 
 Use `/ux-design` to author. Validate with `/ux-review` before passing to `/team-ui`.
+
+> **Accessibility requirements sit OUTSIDE `design/ux/` on purpose.** They are a
+> project-wide standard the per-screen specs consult, not a spec for one screen.
+> `.claude/docs/workflow-catalog.yaml`, the Pre-Production, Production and Polish
+> gates, and `/architecture-review` all check `design/accessibility-requirements.md`
+> at that exact path. Do not "tidy" it under `design/ux/` — every one of those
+> checks would stop matching, and the Technical Setup → Pre-Production gate would
+> become unpassable. `/ux-design` states the same rule at its `accessibility` mode.

design/registry/entities.yaml

@@ -21,7 +21,10 @@
 #               Section C/D writes to conflict-check new entities/formulas)
 #             /consistency-check (primary input — grep-first, GDD-second)
 #             /review-all-gdds (Phase 1 — baseline for Phase 2 checks)
-#             /architecture-review (data structure and interface validation)
+#             /design-review (Phase 1 — cross-doc facts, in place of sibling GDDs)
+#             /content-audit (Step 2 — planned named-content count)
+#             /balance-check (Phase 3 — intended constant/formula values)
+#             /propagate-design-change (Step 3 — downstream GDD impact via referenced_by)
 #
 # SEARCH PATTERNS (for skills using Grep):
 #   All entity names:        Grep pattern="^  - name:" path="design/registry/entities.yaml"