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/docs/templates/architecture-decision-record.md

@@ -4,6 +4,19 @@
 
 [Proposed | Accepted | Deprecated | Superseded by ADR-XXXX]
 
+> **Who may move this to `Accepted`: the user, or `technical-director` on the
+> user's explicit confirmation. No other agent, and no skill on its own.**
+> Stated here because every consumer of this field enforces the *consequences*
+> of acceptance (stories referencing a `Proposed` ADR are set `Blocked`; epics
+> require `Accepted`), so something has to say who may produce it. `technical-director` is the role `coordination-rules.md`
+> already escalates technical conflicts to, and an ADR is exactly that decision
+> made durable.
+>
+> This does **not** relax the existing rule that `Status: Accepted` is never set
+> without explicit user confirmation — it narrows *which agent* may set it once
+> that confirmation exists. An agent that believes an ADR is ready says so and
+> escalates; it does not edit this field.
+
 ## Date
 
 [YYYY-MM-DD — when this ADR was written]
@@ -31,6 +44,7 @@ chosen approach.]
 |-------|-------|
 | **Engine** | [e.g. Godot 4.6 / Unity 6 / Unreal Engine 5.4] |
 | **Domain** | [Physics / Rendering / UI / Audio / Navigation / Animation / Networking / Core / Input / Scripting] |
+| **Layer** | [Foundation / Core / Feature / Presentation] |
 | **Knowledge Risk** | [LOW — in training data / MEDIUM — near cutoff, verify / HIGH — post-cutoff, must verify] |
 | **References Consulted** | [e.g. `docs/engine-reference/godot/modules/physics.md`, `breaking-changes.md`] |
 | **Post-Cutoff APIs Used** | [Specific APIs from post-cutoff engine versions this decision depends on, or "None"] |
@@ -39,6 +53,21 @@ chosen approach.]
 > **Note**: If Knowledge Risk is MEDIUM or HIGH, this ADR must be re-validated if the
 > project upgrades engine versions. Flag it as "Superseded" and write a new ADR.
 
+> **`Layer` is the ADR's own layer, not the referencing epic's — and it is a
+> different taxonomy from `Domain`.** Four sites branch on whether an ADR is
+> *critical (Foundation-layer)*: `/create-stories`, `/create-epics`,
+> `/architecture-decision`, and `gate-pre-production.md`. At `standard`,
+> `/create-stories` **stops** for a missing critical ADR and only **warns** for a
+> non-critical one, so this row decides whether a run halts. Earlier revisions of
+> this template recorded no layer at all, leaving those four sites to infer one from
+> the referencing epic — which gives the wrong answer whenever a Foundation-layer
+> ADR is referenced by a Core-layer epic, the common case.
+>
+> The vocabulary is the same `Foundation / Core / Feature / Presentation` that
+> epics and stories already carry — do not invent a fifth value, and do not
+> reuse a `Domain` value here. `Domain` says *what part of the engine this
+> touches*; `Layer` says *how early in the build it must exist*.
+
 ## ADR Dependencies
 
 | Field | Value |