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/error-recovery-protocol.md

@@ -0,0 +1,59 @@
+# Error Recovery Protocol
+
+Shared procedure for any skill that spawns agents via the `Agent` tool. Referenced from the
+`## Error Recovery Protocol` section of each orchestration/review skill. Those
+skills keep the two load-bearing imperatives (surface immediately, produce a
+partial report) inline, and keep their own **Common blockers** list inline —
+those are skill-specific. This file holds the full four-step procedure.
+
+## Trigger 0 — verify the artifact before reading the response
+
+**Before applying anything below, and before treating a phase as complete: if
+the return contract named a path, check that the path exists.** A named
+artifact that is not on disk is a FAILED PHASE, no matter how the agent's
+response reads.
+
+This trigger exists because the three below are not sufficient. They fire on
+BLOCKED, on an error, and on "cannot complete" — and an agent can fail in a way
+that is none of those. Observed live: a `devops-engineer` spawned
+as half of a parallel phase ran **26 tool calls and ~31,600 tokens**, then
+returned a single fluent preamble — "I'll verify the build infrastructure…" —
+with no path, no summary, no BLOCKED item, and **no file written**. Nothing in
+steps 1–4 matches that shape. An orchestrator reading the transcript sees a
+plausible response and advances, and half a parallel phase disappears with no
+signal at all.
+
+The work was not lost — resumed with an explicit "you did not honour the return
+contract" message, the same agent completed in **one tool call**, because its
+investigation was still in context. Only the write-and-return step had failed.
+So the recovery is cheap; the detection is the hard part, and the detection
+cannot come from reading the response.
+
+**A fluent response is not evidence that a phase ran.** The artifact is —
+observe the artifact, not the transcript. The rule applies to sub-agents
+exactly as it does to skills.
+
+When the path is missing:
+1. Do **not** advance the pipeline or summarise the phase as done.
+2. Resume the agent, naming the unmet contract explicitly and telling it that
+   "I could not write" is a valid answer but silence is not. Prefer resuming
+   over re-spawning — the context is usually still there, and a re-spawn pays
+   for the whole investigation again.
+3. If the second attempt also produces nothing, treat it as BLOCKED and apply
+   steps 1–4 below.
+
+---
+
+If any spawned agent returns BLOCKED, errors, or cannot complete:
+
+1. **Surface immediately** — report "[AgentName]: BLOCKED — [reason]" to the user
+   before continuing to dependent phases.
+2. **Assess dependencies** — check whether the blocked agent's output is required
+   by subsequent phases. If yes, do not proceed past that dependency point without
+   user input.
+3. **Offer options** via `AskUserQuestion`:
+   - Skip this agent and note the gap in the final report
+   - Retry with narrower scope
+   - Stop here and resolve the blocker first
+4. **Always produce a partial report** — output whatever was completed. Never
+   discard work because one agent blocked.