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/story-readiness/CONTRACT.md

@@ -0,0 +1,71 @@
+# /story-readiness — Handoff Contract
+
+## Role in Pipeline
+Validates that a story file contains everything a developer needs to begin
+implementation and produces a READY / NEEDS WORK / BLOCKED / NOT ASSESSED verdict — sits between
+`/create-stories` and `/dev-story`, acting as a blocking gate before any code is written.
+
+## Inputs Required
+
+### Files That Must Exist
+| File | Required Fields / Sections | Read-Only? |
+|------|---------------------------|-----------|
+| `production/epics/[epic-slug]/story-NNN-[slug].md` | All header fields (`Status:`, `Layer:`, `Type:`, `Manifest Version:`), `## Context` (GDD path, TR-ID, ADR reference, Engine Notes, Control Manifest Rules), `## Acceptance Criteria`, `## Test Evidence`, `## Dependencies`, `## Out of Scope` | Yes |
+| `docs/architecture/control-manifest.md` | `Manifest Version:` date in header, layer rules | Yes (if exists) |
+| `docs/architecture/tr-registry.yaml` | `id`, `status` fields per TR entry | Yes (if exists) |
+| `docs/architecture/adr-NNNN-[slug].md` (all ADRs referenced in stories) | `Status:` field | Yes |
+| `design/gdd/systems-index.md` | Which systems have approved GDDs | Yes |
+
+### Preconditions
+- The story file being validated was produced by `/create-stories` (or follows the same format)
+- For `sprint` scope: a sprint file exists in `production/sprints/` with story path references
+- For `all` scope: `production/epics/` directory exists and contains story files
+
+## Outputs Produced
+
+### Files Written
+None. This skill is strictly read-only and produces no file modifications under any circumstance.
+
+### Output Guarantees
+- A verdict of READY, NEEDS WORK, BLOCKED or NOT ASSESSED is produced for every story file evaluated. `NOT ASSESSED` is not a synonym for `BLOCKED`: BLOCKED names a real, listable obstacle, while NOT ASSESSED means the story could not be evaluated at all. An empty scope yields `NOT ASSESSED — no stories in scope`, never a `Ready: 0 / Needs Work: 0 / Blocked: 0` summary over an empty list
+- Every non-READY verdict includes a specific gap list with fix instructions for each failing checklist item
+- Every BLOCKED verdict names the specific blocker (missing dependency story path, Proposed ADR ID, or unresolved design question marker)
+- For `sprint` scope: a sprint-level escalation warning is prepended if any Must Have story is not READY
+- The skill offers to draft missing sections in conversation but never uses Write or Edit tools
+
+## Immutability Rules
+- READS but does NOT modify: story files, `docs/architecture/control-manifest.md`, `docs/architecture/tr-registry.yaml`, all ADR files, `design/gdd/systems-index.md`, sprint files, any referenced asset files (existence-only Glob checks)
+- MODIFIES: nothing
+
+## Hard Constraints (Never Violate)
+- Never use Write or Edit tools under any circumstances
+- Never draft corrections directly into files — offer drafts in conversation only
+- Never mark a story READY if its governing ADR has `Status: Proposed`
+- Never mark a story READY if a dependency story file is missing or has `Status: Draft`
+- Never re-read the same ADR file multiple times in one run — cache ADR statuses after the first read
+- Never penalize a story for missing `Manifest Version:` if `control-manifest.md` does not exist
+- Never penalize a story for missing TR-ID if `tr-registry.yaml` does not exist
+
+## Downstream Skill Expects
+**Next skill:** /dev-story
+
+It will rely on this skill's verdict as follows:
+- If verdict is READY: `/dev-story` proceeds with implementation using the story file as its source of truth
+- If verdict is NEEDS WORK or BLOCKED: `/dev-story` must not be run until the story is corrected and re-validated
+- `/dev-story` reads the same story fields this skill validates — a READY verdict is an implicit guarantee that those fields are present, parseable, and internally consistent:
+  - `Type:` field is set to a valid story type
+  - `## Acceptance Criteria` contains specific, testable checkbox items
+  - `## Test Evidence` specifies a concrete evidence path
+  - The governing ADR exists and has `Status: Accepted`
+  - `Manifest Version:` matches the current control manifest
+  - `TR-ID` in `## Context` is present and resolves in `docs/architecture/tr-registry.yaml` (when the registry exists)
+  - `## Dependencies` section is present (may say "None")
+  - `## Out of Scope` section is present (checked for existence; `/dev-story` uses it to enforce implementation boundaries)
+
+## Known Fragile Points
+- If `control-manifest.md` is regenerated with a new `Manifest Version:` date, every story that embeds the old date will fail the manifest version check — a bulk update of all story `Manifest Version:` fields is required before stories can pass readiness again
+- If an ADR is silently renamed or moved after stories reference it by ID, the ADR file-existence check will BLOCK those stories even though the decision content is unchanged
+- The manifest version comparison is a string date match, not a semantic version comparison — if the date format changes (e.g., from `2026-01-15` to `Jan 15 2026`), all stories will fail the check regardless of actual currency
+- Asset existence checks use Glob — on Windows, path separator mismatches (`\` vs `/`) may cause a Glob miss that incorrectly flags an asset as missing
+- The TR-ID status check auto-passes if the registry does not exist, which means stories written before TR tracking was introduced will always pass this check even if they contain invalid or placeholder IDs like `TR-[system]-???`
+- For `sprint` scope, the skill depends on sprint file formatting to extract story paths — if the sprint file format changes, story paths may not be parsed and the scope silently reduces to zero stories validated