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/scope-check/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: scope-check
-description: "Analyze a feature or sprint for scope creep by comparing current scope against the original plan. Flags additions, quantifies bloat, and recommends cuts. Use when user says 'any scope creep', 'scope review', 'are we staying in scope'."
+description: "Scope creep check — current scope versus the original plan. Flags additions, quantifies bloat, recommends cuts. 'Any scope creep?'"
 argument-hint: "[feature-name or sprint-N]"
 user-invocable: true
 allowed-tools: Read, Glob, Grep, Bash
@@ -56,6 +56,13 @@ Generated: [Date]
 ### Current Scope
 [List of items currently implemented or in progress]
 
+> **If Phase 4 will return NOT ASSESSED, do not render the numeric block below.**
+> Replace the counts and the Bloat Score with
+> `Baseline unusable — see verdict` and give the reason. A rendered
+> `Original items: 0 / Net scope change: 0%` one section above a NOT ASSESSED
+> verdict re-creates the exact "0% reads as on track" hazard Phase 4 exists to
+> kill, one phase earlier — and readers trust a number over a caveat.
+
 ### Scope Additions (not in original plan)
 | Addition | Source | When | Justified? | Effort |
 |----------|--------|------|------------|--------|
@@ -98,11 +105,30 @@ Assign a canonical verdict based on net scope change:
 | 25–50% | **FAIL** | Significant Creep — must cut or formally extend timeline |
 | >50% | **FAIL** | Out of Control — stop, re-plan, escalate to producer |
 
+**Before applying that table, check that the percentage means something.** Emit
+**NOT ASSESSED** instead — never a computed percentage — when any of:
+
+- The **baseline document exists but enumerates no scope items** (all headings,
+  placeholders, or `[TO BE CONFIGURED]`). Phase 1 stops when the file is *absent*;
+  this is the case where it is present and empty, and it is the more dangerous
+  one, because zero items yields a 0% net change that renders as **PASS — On
+  Track**. Nothing was compared. Nothing was on track.
+- The **current state cannot be determined** — no related source files, no commits
+  in the window, nothing in progress to read. Comparing a real baseline against an
+  unreadable present is not a 0% change.
+- The denominator would be zero for any other reason. A percentage computed from
+  no baseline items is not a small number; it is not a number.
+
+`NOT ASSESSED` **outranks PASS** (a comparison that never happened has not shown
+scope is on track) and **ranks below CONCERNS and FAIL** (measured creep is more
+actionable than an unmeasurable baseline).
+
 Output the verdict prominently:
 
 ```
-**Scope Verdict: [PASS / CONCERNS / FAIL]**
+**Scope Verdict: [PASS / CONCERNS / NOT ASSESSED / FAIL]**
 Net change: [+X%] — [On Track / Minor Creep / Significant Creep / Out of Control]
+           [or: NOT ASSESSED — [which side could not be read, and why]]
 ```
 
 ---
@@ -112,6 +138,10 @@ Net change: [+X%] — [On Track / Minor Creep / Significant Creep / Out of Contr
 After presenting the report, offer concrete follow-up:
 
 - **PASS** → no action required. Suggest re-running before next milestone.
+- **NOT ASSESSED** → say which side was unreadable and what would fix it (populate
+  the baseline document, or point the skill at where the work actually lives).
+  Do not offer a re-run against the same inputs — it will produce the same
+  non-answer.
 - **CONCERNS** → offer to identify the 2–3 additions with best cut ratio. Reference `/sprint-plan update` to formally re-scope.
 - **FAIL** → recommend escalating to producer. Reference `/sprint-plan update` for re-planning or `/estimate` to re-baseline timeline.